I’m not very familiar with the legal details, but I assume the distinction is general access to the internet being considered a utility, while access to platforms being considered something like a privilege. E.g. roads shouldn’t discriminate based on destination, but that doesn’t mean the destination has to let you in.

edit: As to why Americans don’t seem as concerned with it (which is realize I didn’t address): I think most people see it as a place, like a restaurant. You can be kicked out if you are violating policies or otherwise disrupting their business, which can include making other patrons uncomfortable. Of course there are limits which is why we have anti-discrimination laws.

The landmark case in the United States is throttling of Netflix by Comcast. Essentially, Comcast held Netflix customers hostage until Netflix paid (which they did).

It’s important to understand that many providers (Comcast, AT&T), also own the channels (NBC, CNN, respectively). They have an interest in charging less for their and their partners content, and more for their competitors content, while colluding to raise prices across the board (which they have done in the past with television and telephone service).

Collectively, they all have an interest in preventing new entrants to the market. The fear is that big players (Google, Amazon) will be able to negotiate deals (though they’d probably prefer not to), and new or free technologies (like PeerTube) will get choked out.

Net neutrality is somewhere where the American attitude towards corporations being able to do whatever to their customers conflicts with the American attitude that new companies and services must be able to compete in the marketplace.

You’re right to observe that individuals don’t really enter into it, except that lots of companies are pushing media campaigns to sway public opinion towards their own interests. You’re seeing those media campaigns leaking out.

Switching to the individual perspective.

I just don’t want to pay more for the same service. In living memory Americans have seen their gigantic monopolistic telecommunications company get broken up, and seen prices for services drop 100 fold; more or less as a direct consequence of that action.

As other posts have noted, the ISP situation in the US is already pretty dire unless you’re a business. Internet providers charge whatever they can get away with and have done an efficient job of ensuring customers don’t have alternatives. Telephone service got regulated, but internet service did not.

Re-reading your post after diving on this one… We’re not really concerned about the same gatekeepers. I don’t think any American would be overly upset to see players like Amazon, Facebook, Google, Twitter, and Netflix go away and I wouldn’t be surprised to see one or more of those guys implode as long as they don’t get access to too much of the infrastructure.

Right-leaning US Citizen here. I’ll attempt to answer this as best as I can.

Net neutrality is being pushed by the media because it “fights discrimination”, and they blame the “fascist, nazi right” for it’s repeal (and they’re correct, except for the “fascist, nazi” bit). But without net neutrality, the ISPs still have an incentive to provide equal service, because otherwise they’ll lose customers (for obvious reasons).

I can’t speak to why open-source advocates are also pushing for net neutrality, because (in my opinion) the government shouldn’t be involved in how much internet costs. I do remember this article was moderately interesting, saying that the majority of root DNS servers are run by US companies. But, that doesn’t really faze me. As soon as people start censoring, that get backlash whether the media covers it or not

Side note, the reason you don’t see the protests against the “gatekeepers” is that most of the mainstream media isn’t accurately covering the reaction of the people to the censorship. I bet you didn’t know that InfoWars was the #1 news app with 5 stars on the Apple app store within a couple of weeks of them getting banned from Facebook, etc. I don’t really have any opinion about Alex Jones (lots of people on the right don’t agree with him), but you can bet I downloaded his app when I found out he got banned.

P.S. I assumed that InfoWars was what you were referring to when you said “removing some controversial users” P.P.S. I just checked the app store again, and it’s down to #20 in news, but still has 5 stars.

One part of it is that we already have net neutrality, and it’s easier to try to hang on to a regulation than to create a new one.

Done. Thank you very much for the suggestion.

Maybe there should be some sort of standardized directory?…

Thanks! Sudoku solver has been my go-to problem even since I started learning Haskell. I used it to learn and explore various facets of Haskell.

Yes, that’s usually true. Because you have more places to embed the bits, and you can use more LSBs producing usually a less noisy image.

Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.

In this article, resistance to governments constantly comes up as a theme of his work. He also pushed for his tech to be used to help resist police states like with the Arab Spring example. Although he mainly increased the baseline, the tool has been pushed for resisting governments and articles like that could increase perception that it was secure against governments.

This nation-state angle didn’t come out of thin air from paranoid, security people: it’s the kind of thing Moxie talks about. In one talk, he even started with a picture of two, activist friends jailed in Iran in part to show the evils that motivate him. Stuff like that only made the stuff Drew complains about on centralization, control, and dependence on cooperating with surveillance organization stand out even more due to the inconsistency. I’d have thought he’d make signed packages for things like F-Droid sooner if he’s so worried about that stuff.

Expecting Signal to protect anyone specifically targeted by a nation-state is a huge misunderstanding of the threat models involved.

And yet, Signal is advertising with the face of Snowden and Laura Poitras, and quotes from them recommending it.

What kind of impression of the threat models involved do you think does this create?

We’ve had IRC from the 1990s, ever wonder why Slack ever became a thing? Ossification of a decentralized protocol.

I’m sorry, but this is plain incorrect. There are many expansions on IRC that have happened, including the most recent effort, IRCv3: a collectoin of extensions to IRC to add notifications, etc. Not to mention the killer point: “All of the IRCv3 extensions are backwards-compatible with older IRC clients, and older IRC servers.”

If you actually look at the protocols? Slack is a clear case of Not Invented Here syndrome. Slack’s interface is not only slower, but does some downright crazy things (Such as transliterating a subset of emojis to plain-text – which results in batshit crazy edge-cases).

If you have a free month, try writing a slack client. Enlightenment will follow :P

Alternative distribution mechanisms are not used by 99%+ of the existing phone userbases, providing an APK is indeed correctly viewed as harm reduction.

I’d dispute that. People who become interested in Signal seem much more prone to be using F-Droid than, say, WhatsApp users. Signal tries to be an app accessible to the common person, but few people really use it or see the need… and often they are free software enthusiasts or people who are fed up with Google and surveillance.

Ossification of a decentralized protocol.

IRC isn’t decentralised… it’s not even federated

and cause irreparable harm to trust in Google from both users and developers

You have good points except this common refrain we should all stop saying. These big companies were caught pulling all kinds of stuff on their users. They usually keep their market share and riches. Google was no different. If this was detected, they’d issue an apologetic press release saying either it was a mistake in their complex, distribution system or that the feature was for police with a warrant with it used accordingly or mistakenly. The situation shifts from everyone ditch evil Google to more complicated one most users won’t take decisive action on. Many wouldn’t even want to think to hard into it or otherwise assume mass spying at government or Google level is going on. It’s something they tolerate.

I think that trusting Google not to want to muck with Signal is probably honestly a safe bet for most users.

The problem is that moxie could put things in the app if enough rubberhose (or money, or whatever) is applied. I don’t know why this point is frequently overlooked. These things are so complex that nobody could verify that the app in the store isn’t doing anything fishy. There are enough side-channels. Please stop trusting moxie, not because he has done something wrong, but because it is the right thing to do in this case.

Another problem: signals servers could be compromised, leaking the communication metadata of everone. That could be fixed with federation, but many people seem to be against federation here, for spurious reasons. That federation & encryption work together is shown by matrix for example. I give that it is rough on the edges, but at least they try, and for now it looks promising.

Finally (imho): good crypto is hard, as the math behind it has hard constraints. Sure, the user interfaces could be better in most cases, but some things can’t be changed without weakening the crypto.

Maybe a skilled user with GPG is more secure than Signal

Only if that skilled user contacts solely with other skilled users. It’s common for people to plaintext reply quoting the whole encrypted message…

And in all cases of installation, you’re trusting Signal at some point.

Read: F-Droid is for open-source software. No trust necessary. Though to be fair, even then the point on centralization still stands.

Yes, Google could replace your copy of Signal with a nefarious version for their own purposes, but that’d be amazingly dumb: it’d be quickly detected and cause irreparable harm to trust in Google from both users and developers.

What makes you certain it would be detected so quickly?

By May 25, most corporates had just amended their Privacy Policy volumes and annoyed consumers were forced to clicked through to accept them without reading.

I don’t know why people find this so hard to understand, but the entire point of the GDPR is that you cannot comply with it simply by adding more terms to your Terms of Service for people to sign away their rights without reading. That’s not how it works.

Excuse me if I misunderstand, but isn’t it still the case that they can add terms to their privacy policy, then tell users to either check all the boxes or leave?

I don’t know why people find this so hard to understand, but the entire point of the GDPR is that you cannot comply with it simply by adding more terms to your Terms of Service for people to sign away their rights without reading. That’s not how it works.

Have the various aspects of GDPR been applied/tested in court yet?

I hate it when people say “look at what this person built!” or “look at what this person supports!” as though it’s proof the person’s opinion is compromised. It’s totally expected that someone who holds this opinion would follow through on it by building something around it. If you’d like to suggest they’re just saying what’s convenient for their position, you can use as much popular psychology as much as you want; as is common with pop-psych, you’ll find false-positives everywhere.

But how fast is the turnover? Was that common knowledge at the time? What else have we yet to realize?

Author here: brain worms? Lack of training in probability and statistics? I went through a LOT of reading new-to-me things in the course of trying to figure all this out.

Not just technical people either: an old friend used to train laypeople to use it on NoScript forums. He said there was a small, but steady, stream of them concerned about privacy and/or speeding up machines.

Does it warn you if the scripts contents have changed?

If so, it might mitigate a little this huge security hole hidden in plain sight… but I’m not much sure…

Apple chooses to not support WebM (eight years and counting!), and you choose to use Safari. Better alternatives exist.

I think for the majority it’s because a lot of their knowledge is stored on the internet with their working memory copy simply being how to quickly look up the documentation to get the right answer.

I think for the majority it’s because the internet has become an extension of their working memory and without it they flounder simply because they haven’t needed to commit to memory the details, or anything much more than were to find them when needed.

The best analogy I can come up with is mental arithmetic, it used to be that you could take someone to the white board and ask them to work out a long division question or complex multiplication and most would be able to do so with little to no stress. With the prevalence of calculators nobody bothers to remember how to do long division or factorisation of difficult multiplication because they know how to use a calculator that does it quicker (we are animals of path of least resistance after all.)

A white board interview where you’re describing abstract concepts would probably solve a lot of the worries, because that tends to be what most people remember, with the details filled in by a few searches of the documentation.

The best that I’ve found is to just ask them to explain some tech that’s listed on their resume. You’ll really quickly be able to tell if its something they understand or not.

My team does basic networking related stuff and my first question for anyone that lists experience with network protocols is to ask them to explain the difference between TCP and UDP. A surprising number of people really flounder on that despite listing 5+ years of implementing network protocols.

A sample of actual work expected of the prospective employee is fair. There are pros and cons to whether it should be given ahead of time or only shown there, but I lean towards giving it out in advance of the interview and having the candidate talk it through.

Note that this can be a hard sell, as it requires humility on the part of the individual and the institution. If your organization supports an e-commerce platform, you probably don’t get to quiz people on quicksort’s worst-case algorithmic complexity.

I recently went through a week of interviewing as the conclusion of the Triplebyte process, and I ended up enjoying 3 of the 4 interviews. There were going to be 5, but there was a scheduling issue on the company’s part. The one I didn’t enjoy involved white board coding. I’ll tell you about the other three.

To put all of this into perspective, I’m a junior engineer with no experience outside of internships, which I imagine puts me into the “relatively easy to interview” bucket, but maybe that’s just my perception.

The first one actually involved no coding whatsoever, which surprised me going in. Of the three technical interviews, two were systems design questions. Structured well, I enjoy these types of questions. Start with the high level description of what’s to be accomplished, come up with the initial design as if there was no load or tricky features to worry about, then add stresses to the problem. Higher volume. New features. New requirements. Dive into the parts that you understand well, talk about how you’d find the right answer for areas you don’t understand as deeply. The other question was a coding design question, centered around data structures and algorithms you’d use to implement a complex, non-distributed application.

The other two companies each had a design question as well, but each also included two coding questions. One company had a laptop prepared for me to use to code up a solution to the problem, and the other had me bring my own computer to solve the questions. In each case, the problem was solvable in an hour, including tests, but getting it to the point of being fully production ready wasn’t feasible, so there was room to stretch.

By the time I got to the fourth company and actually had to write code with a marker on a whiteboard I was shocked at how uncomfortable it felt in comparison. One of my interviews was pretty hostile, which didn’t help at all, but still, there are many, far better alternatives.

There are extensive resources to help with the evangelism side of things.

They should be able to give solid reasoning for big-O. I do think it’s necessary to know the basics of big-O analysis.

I’d argue that if someone is familiar with big-O but not with profiling, their knowledge is as good as nothing. Premature optimization is the bane of software development.

I ask a quick question about their technical experience at the beginning. […] I prefer not looking at resumes…

Couldn’t you glean the same knowledge by looking at their résumé?

Right. We develop the resilience to fight through those “not intrinsically fun” problem-solving tasks. In fact, it’s something every single one of us did when we first began learning how to code.

(Grumpy C programmer who’s dabbled with Rust)

I think you are both right. :) Most of the “fighting the borrow checker” happens when one doesn’t have much experience with Rust. As one gets better, I can only assume that one gets better at coming up with designs which lend themselves to fewer borrow checker fights.

I think this is very similar to the pain experienced by a C programmer (really any procedural language) trying something radically different - e.g., common lisp. From my own experience, writing lisp was a pain at first because I just tried to write the code just as I would in C - because that’s just what I’m used to. With time and practice, one gets better at the new language and dealing with its quirks. (For the record, I lost interest in common lisp not long after my first aha moment.)

So, I guess one can define two points in time for a Rust developer: the novice and the expert. For the novice, I think ahu’s statement is more or less correct. For the expert, you are correct. On that note, the steepness of the learning curve for Rust is interesting - if it is too steep, not enough novices will have the gumption to take the hit in productivity to practice enough to become experts.

We’ve spent about half a century refining the email interface: it’s pretty good.

We’ve spent about half a century refining the email interface. Very good clients exist…. but most people still use GMail regardless.

That’s typically the result of a poor email client. We’ve had threaded discussions since at least the early 90s, and we’ve learned a lot about how to present them well. Tools such as gnus do a very good job with this — the rest of the world shouldn’t be held back because some people use poor tools.

I have never seen an email client that presented threaded discussions well. Even if such a client exists, mailing-list discussions are always a mess of incomplete quoting. And how could they not be, when the whole mailing list model is: denormalise and flatten all your structured data into a stream of 7-bit ASCII text, send a copy to every subscriber, and then hope that they’re able to successfully guess what the original structured data was.

You could maybe make a case for using an NNTP newsgroup for project discussion, but trying to squeeze it through email is inherently always going to be a lossy process. The rest of the world shouldn’t be held back because some people use poor tools indeed - that means not insisting that all code discussion has to happen via flat streams of 7-bit ASCII just because some people’s tools can’t handle anything more structured.

I agree with there being value in multipolar standards and decentralization. Between a structured but centralised API and an unstructured one with a broader ecosystem, well, there are arguments for both sides. But insisting that everything should be done via email is not the way forward; rather, we should argue for an open standard that can accommodate PRs in a structured form that would preserve the very real advantages people get from GitHub. (Perhaps something XMPP-based? Perhaps just a question of asking GitHub to submit their existing API to some kind of standards-track process).

…the new PR will lose the history of the old PR.

Why not just link to it?

This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.

That strikes me as disingenuous as well. Email is older. Of course it has more clients, with varying degrees of maturity & ease of use. That has no bearing on whether the GitHub API or an email-based workflow is a better solution. Your point is taken; the GitHub API is not yet “Just Add Water!”-tier. But the clients and maturity will come in time, as they do with all well-used interfaces.

Github can legally delete projects or users with or without cause.

Whoever is hosting your mailing list archives, or your mail, can do the same. It’s not unheard of.

But of course my own maildir on my own machine will remain.

Meanwhile, the local copy of my git repo will remain.

I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.

I’m fairly certain that it’s a website of some sort—that is, if you intend on using a definition of “perfect” that scales to those with preferences & levels of experience that differ from yours.

(author here)

Whether using the web UI or the API, one is still performing the quoted steps

Indeed, but the difference between using the UI and the API, is that the latter is much easier to build tooling around. For example, to start contributing to a random GitHub repo, I need to do the following steps:

• Tell my Emacs to clone & fork it. This is as simple as invoking a shortcut, and typing or pasting the upstream repo name. The integration in the background will do the necessary forking if needed. Or I can opt not to fork, in which case it will do it automatically later.
• Do the changes I want to do.
• Tell Emacs to open a pull request. It will commit my changes (and prompt for a commit message), create the branch, and open a PR with the same commit message. I can use a different shortcut to have more control over what my IDE does, name the branch, or create multiple commits, etc.

It is a heavily customised workflow, something that suits me. Yet, it still uses GitHub under the hood, and I’m not limited to what the web UI has to offer. The API can be built upon, it can be enriched, or customised to fit one’s desires and habits. The difference in what I need to do to get the same steps done differs drastically. Yes, my tooling does the same stuff under the hood - but that’s the point, it hides those detail from me!

(which notably never mention the browser).

Near the end of the article I replied to:

“Tools can work together, rather than having a GUI locked in the browser.”

From this, I concluded that the article was written with the GitHub web UI in mind. Because the API composes very well with other tools, and you are not locked into a browser.

That’s typically the result of a poor email client.

I used Gnus in the past, it’s a great client. But my issue with long threads and lots of branches is not that displaying them is an issue - it isn’t. Modern clients can do an amazing job making sense of them. My problem is the cognitive load of having to keep at least some of it in mind. Tools can help with that, but I can only scale so far. There are people smarter than I who can deal with these threads, I prefer not to.

What he sees as a benefit I see as a detriment: the new PR will lose the history of the old PR. Again, I think this is a tooling issue: with good tools resurrecting an ancient thread is just no big deal. Why use poor tools?

The new PR can still reference the old PR, which is not unlike having an In-Reply-To header that points to a message not in one’s archive. It’s possible to build tooling on top of this that would go and fetch the original PR for context.

Mind you, I can imagine a few ways the GitHub workflow could be improved, that would make this kind of thing easier, and less likely to loose history. I’d still rather have an API than e-mail, though.

This is somewhat disingenuous: while GitHub does indeed have an API, the number & maturity of GitHub API clients is rather less than the number & maturity of SMTP+IMAP clients. We’ve spent about half a century refining the email interface: it’s pretty good.

Refining? You mean that most MUAs look just like they did thirty years ago? There were many quality of life improvements, sure. Lots of work to make them play better with other tools (this is mostly true for tty clients and Emacs MUAs, as far as I saw). But one of the most wide-spread MUA (gmail) is absolutely terrible when it comes to working with code and mailing lists. Same goes for Outlook. The email interface story is quite sad :/

There’s a huge difference between being able to easily download all of one’s email (e.g. with OfflineIMAP) and only being at the mercy of one’s email provider going down, and being at the mercy of GitHub preserving its API for all time.

Yeah, there are more options to back up your mail. It has been around longer too, so that’s to be expected. Email is also a larger market. But there are a reasonable number of tools to help backing up one’s GitHub too. And one always makes backups anyway, just in case, right?

So yeah, there is a difference. But both are doable right now, with tools that already exist, and as such, I don’t see the need for such a fuss about it.

I use & like GitHub, and I don’t think email is perfect. I think we’re quite aways from the perfect git UI — but I’m fairly certain that it’s not a centralised website.

I don’t think GitHub is anywhere near perfect, especially not when we consider that it is proprietary software. It being centralised does have advantages however (discoverability, not needing to register/subscribe/whatever to N+1 places, and so on).

You would end up with a more secure system from attackers with less resources. For example, you can make your system secure to all common methods used by script kiddies but what happens when a state-level actor is attacking your system? In this case and as your threats get more advanced I agree with the article. In higher levels of threats it becomes a problem of economics.

IME all of the examples this page give are too costly to be worth it, almost all of the time: privilege separation, asset depreciation, exploit mitigation and detection are all very costly to implement while representing only modest barriers to skilled attackers.

How do you figure it’s too costly? If anything, all these things are getting much easier, as they become primitive to deployment environments, and frameworks. Additionally, there are services out there that scan dep. vulnerabilities if you give them a Gemfile, or access to your repo.

Limited resources would be better expended on “perfect” security measures; someone who expended the same amount of effort while following the truism and focusing on eliminating vulnerabilities entirely would end up with a more secure system.

Perfect it all you want. The weakest link is still an employee who is hung over and provides their credentials to a fake GMail login page. (Or the equivalent fuck up) If anything, what’s costly is keeping on your employees to not take shortcuts, and on stay alert to missing access cards, rouge network devices in the office, badge surfing, and that they don’t leave their assets lying around.

I certainly hope you’re correct that the market will demand better. I think it’s possible, but I’m not as optimistic as you. Getting end users to care about security, even when the lack of it directly harms them, isn’t easy.

The second a competitor comes along that doesn’t have this nonsense built-in, companies that sell computers will begin to source their CPUs from them.

There’s been competitors to Intel without the nonsense built in, with simpler architectures, faster at one point, and so on. Many went bankrupt, the products were withdrawn, or the company got acquired. So, your claim has to be assumed false by default given the market history is exactly the opposite. The combo of monopolistic tactics by Intel/IBM/Microsoft and the lock-in to x86 software made that happen. On x86 side, it was mostly the same with AMD happening because IBM forced it to happen. There’s one, surviving, third party that focused on lowest, energy usage. The Centaur’s were sold by VIA but VIA was losing boatloads of money. So, you don’t have a lasting, success story that was able to do non-coerced license of x86 for high-performance chips.

The good news is the prevalence of doing everything in the browser already got hardware diversity in via netbooks and tablets. The new architecture having excellent browser and codec support might be enough to get some of that market. Throw in sync with all devices plus online, private backups. There’s some potential. I’ve also been toying with ideas about cloud servers (esp for web stuff), network appliances, kiosks, and so on. Whereas, taking down Intel/AMD will require x86 support for legacy, x86-optimized apps. Intel publicly threatened to use patent suits on any company that does that.

“People use insecure, poorly designed technologies only when well designed, secure versions of those technologies do not exist.”

That’s nonsense. There are easy-to-use, private solutions in a number of areas. Let’s just say search, chat, email, and backups. The market at large uses the insecure offerings, even those with harder UI. That’s because they thought they were a good deal for every reason but the one you gave: truly private or secure. They don’t care about that. I think the easiest counterpoint is that the top providers of email and ways to hang out with friends are surveillance companies. They know it, private IM’s or group messages aren’t so hard, and they still use the surveillance platforms anyway. That’s hundreds of millions to billions of people. Where’s your market data backing your point a similarly-sized number of people cared enough to switch to DuckDuckGo, Signal, or SpiderOak? I’m cherry-picking things advertised as private that are easy to use with media coverage.

I tried to collect the pros and cons in this article: https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html

I also spoke about this at length in a previous article:

https://drewdevault.com/2018/07/02/Email-driven-git.html

While my general experience with git email is bad (it’s annoying to set up, especially in older versions and I don’t like it’s interface too much), my experience of interaction with projects that do this was generally good. You send a patch, you get review, you send a new, self-contained patch, attached to the same thread… etc, in parallel to the rest of the project discussion. It’s a different flavour, but with a project that is used to the flow, it can really be quite pleasing.

What does it add to just using git by itself?

I think the selling point is precisely that it doesn’t add anything else. Creating a PR involves more steps and context changes than git-format-patch git-send-mail.

I have little experience using the mailing list flow, but when I had to do so (because the project required it) I found it very easy to use and better for code reviews.