To complete the comedy:
What even is the difference between an app and a webpage to the average user (read: computer illiteral person)? It's the shortcut on the desktop/homescreen.
If only you could ship a desktop shortcut to your webpage, that would be a very inexpensive way to develop an app, and what probably most apps could have been.
If you have a webpage open in Safari on iOS, you can click the share button, "View More" and then "Add to Home Screen". It adds an icon to the home screen. Tapping the icon does not open another browser tab but rather spawns a standalone window, like a regular app.
This is how I distribute my "home-cooked" family expenses tool without publishing to App Store.
I find it amusing that, originally, Steve Jobs claimed that web apps were so good that you wouldn't need native apps and would just write web apps for the iPhone and now Apple's approval process is so painful that people prefer to write web apps for the iPhone.
I thought of that story, too, but I'm wondering to what extent it was his genuine belief, versus needing to say something because they didn't yet have a software distribution method he liked.
Reading this 9to5mac post from 2011, it seems at least part of the issue was he didn't think they had the moderation bandwidth (which of course presupposes that they had to have a centralised, monopolistic app distribution platform to begin with).
Tangentially, there's also this bit at the end:
Jobs enthused how there was nothing like the App Store before the iPhone came along. After Mossberg objected that pre-iPhone devices were able to run third-party apps, Jobs responded by saying that the carriers controlled everything, including the design of cell phones, noting there was no easy way for a guy in his bedroom to create programs for cell phones and distribute them with ease. “It’s huge now,” he quipped.
I had a number of Symbian phones in the 2000s, and there definitely were apps clearly made by just regular people. Yes, they way you found out about them was from "best applications for your Nokia smartphone" type websites (of varying levels of jank), or enthusiast forums, so discovery was hard if you didn't know about those. But once you had a link to a .sis or whatever, you just downloaded and installed the thing.
I guess those phones were never popular in the US, where carriers did control everything.
I guess those phones were never popular in the US, where carriers did control everything.
This was also the reason I didn't think the iPhone would be successful. The US carrier environment made it really hard for any phone to show of its benefits and a phone designed for that environment would appear very bad in the rest of the world. I didn't take into account how much Jobs would be able to persuade AT&T. Even then, the iPhone was pretty bad. It didn't support 3G (my old Nokia did), it didn't sync with the Mac without a cloud thing (my old Nokia did), it couldn't make SIP calls over WiFi (my old Nokia did), it couldn't run third-party apps out of the box (my old Nokia did). It wasn't until Apple shipped the iPhone 3G and removed iSync from OS X that they reached parity.
I wouldn't mind the approval process itself that much* but I do mind having to buy a macOS machine and paying Apple ~€100/year just to publish something in App Store.
* Although I do think that sideloading should be available.
Are you running an older version of iOS? Before version 26 it required a web app manifest to open a web page in stand-alone mode, but it was changed to use app mode by default for web pages opened via home screen icons.
The idea is pretty simple: the product is open-source, licensed using a strict license such as the AGPL [...]
Crucially, to gain access to the private repository you must "sign" (i.e. this could just be a "Yes I agree to these terms" checkbox) an agreement of sorts which states that if you publicly host a copy of the private repository your access to this private repository will be revoked.
Quoting the AGPL: (but this clause is in the GPL too)
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.
Not sure how it'd be possible to rectify those two things!
Other than that, I'd say it's not a bad idea; it's just not something you could use the GPL for.
I tried to clarify this a bit more in this comment, but the idea is that there's a license agreement for the source code (e.g. the AGPL), and an agreement for the platform that hosts it and the latter comes with the "you can't mirror the repository" agreement. This isn't really any different from say GitHub saying "If you post illegal content on GitHub you'll be banned": you can't access the platform any more, but you can still use the source code in accordance to its license.
Aha, OK. Making a clear distinction between "license to the codebase" vs "ongoing access to updated versions" is subtle but seems clever. Someone who paid for access and then stopped paying would be well within their rights to distribute the code they received, but not while they retained ongoing access to new versions, and rights covered by the GPL do not in any way imply ongoing access to updates.
If you hold the copyright you can choose to distribute the work under multiple licenses, which may themselves be inconsistent.
You apply AGPL terms to the public version that is not current, you provide a commercial license for customers who want it, and do not offer them access to the source code under the AGPL.
TBH, I’m not sure that three months delay is really that load bearing. But some companies will pay to be able to link AGPL software to their closed source codebase, if it’s for something important. Sencha did this for ExtJS (regular GPL, since it was client side JS).
There's a few vendors out there that basically threaten their customers if they exercise their right under GPL, they will cancel all support contracts. Often, those are codebases that they don't hold all copyright for. So it's not even a new idea, it's generally considered legally sketchy.
The legal argument says that you are not imposing restrictions on the code that they receive, you are imposing restrictions on their ability to access future versions of the code. You may either exercise all of the rights under the AGPL, in which case you don't get the next version but you retain the ability to exercise all of the rights to this version, or you may exercise a subset of them and then get access to the next version.
Several lawyers have had strong opinions on this strategy. They did not agree.
The other issue is that licenses such as the AGPL pass on these rights to all downstream people. And you can't restrict what they do. So you're effectively saying 'don't distribute this'.
The problem is that it's missing why people want open-source languages. They have decades of experience being locked into vendor-specific toolchains. The thing that they want from open source is either a second source or a strong possibility of a second source, including doing in-house things that integrate the tooling. That often rules out GPL-family licenses and definitely rules out anything where the project is structured to ensure that outside contributors cannot become maintainers of a fork.
Do... people normally only hold a phone in their primary hand? I'm left-handed but hold my phone in either hand about equally at random, and kind of just figured everyone did that.
I'm left handed and nearly exclusively hold my phone in my right hand. The cause is simple: at first I held my phone in my right hand, and used my left hand to interact with it. As time went on, I used my right thumb to do more and more things, until it became the primary interaction point.
Similarly I use the mouse with my right hand because in the computer lab growing up the mice didn't have long enough cable to switch over and use my right hand.
left handed people tend to have a dose of ambidextery, as the world really wants us to be right-handed.
left-handed here, but I also do a lot of things with my right hand, like handwriting. It's also my dominant hand on the piano (although the way most pieces are written certainly contributed to that). and yeah, I use both hands on the phone as well
A data point: I'm definitely faster at touchscreen typing in my dominant hand. I can use either (it's not as hard as handwriting), but for anything more than a glance at the screen or a few swipes, it is more comfortable with my dominant hand.
I at the very least start swapping hands when one of my wrists gets tired of holding the 2026 mega-brick form-factor smartphones. You would think it is more common to at least have tried using both hands even as a "righty".
I am right handed and almost exclusively hold my phone in my left hand, so my right hand is completely free to interact with it. I don't know if I just have abnormally short fingers (I don't think so? they look fine), but I find it really awkward to interact with my phone with the same hand that's holding it.
So, if I'm scrolling on my phone, it'll be phone in left hand, scrolling performed with an arbitrary finger of the right hand.
I'm ambidextrous with a slight bias towards fine motor control on the left and coarse motor control on the right. I tend to hold my phone in my left hand because I use my right hand for mice (experience, not innate bias - I can use either, but most computers I used as a child had the mouse pad on the right and moving it didn't make things better [or worse], so I didn't) and so pick up the desire to use the same hand as my pointing-device hand.
Right handed here, and I use both. I probably favour my right a bit more, but from some quick anecdotal testing I seem to type better with my left hand on my phone than my right (although for anything longer than a couple of sentences, I'll use both thumbs to type).
I use my phone with whichever hand is comfortable to reach for it, which is usually my nondominant left because I keep it in that pocket. It strikes me as absurd that someone's handedness might lead them to prefer a hand for one-handed phone use, because I have no preference at all unlike in most domains. But maybe that too is an accessibility blind spot.
Why stop at signedness? Integers should be bignums by default, for much the same reason.
For that matter why stop at integers? Math should be rational by default. This one is very slightly harder to justify because sometimes one really does want IEEE 754 floating point numbers for a calculation, but note the word ‘default.’
I know that we’re all used to machine ints and floats now, so they do not seem surprising, but I suspect that for a layman it would be less surprising for computers not to have problems with negative, large or rational numbers.
I really like the Smalltalk / Lisp choice that integers are things that are stored inline in the pointer but automatically promote to BigInt on overflow. On a 64-bit machine, that typically gives you a 61-bit signed integer as the default type, which is big enough for most things, but which gracefully fails over to a slower path that doesn't lose information on overflow.
That's not appropriate for systems programming, where you need to be able to do arithmetic that definitely won't allocate memory, but for application programming it's almost always the right choice.
For application programming my integers often end up in Postgres which has sized types too, and some correspondence between valid application state and serializable/persistable state can be good.
Also - does this trick work properly with CHERI/CHERIoT?
I suppose you can do similar tricks with float NaN values for a generic 64-bit numeric type…
Yes, though you can actually do better on CHERI systems because you can use the tag bit as the discriminator. On CHERIoT, you can have a union of a 64-bit integer and a pointer taking up the same space as a pointer, so you can use the full range of the integer (unless you want to store more types inline, then you might choose to steal some bits for a discriminator).
This is also not powered by green energy. There are gas pipelines being built directly to data centers for on site generation. Wait times for turbines have gone up years.
We are setting our future on fire so that we can accelerate enshittification.
If they were, it would be an irrelevant distraction. Electricity is fungible. 1 MW of consumption means 1 MW of consumption. If your 1 MW is produced by green energy, that means 1 MW of green energy that isn't available for other uses. Unless it's powered by green energy from production projects built specifically to power that thing, then it's an accounting trick not actually a green shift. And, even then, the huge demand spike may be making green energy less affordable for other uses (up to a certain point, more demand means more economies of scale and pushes prices down. Beyond that, shortages in the supply chain mean that the price goes up).
I was depressed when I was at MS that there were people on the Sustainability Committee, who seemed to genuinely care about not making the planet uninhabitable, who would nevertheless justify running enormous machine-learning jobs because power to Azure could be met with green energy production.
I think this mindset is flawed. You can put yourself in any point in history and you will still find reasons to not have hope for the future. I mean I definitely won't argue the world is perfect, but it's a whole lot better than 100 years ago. or 200 years ago. or 300... Each generation fights its own fight, that's the way it goes.
To be fair, no generations other than those currently alive had to contend with accelerating anthropogenic climate change at this scale.
I mean I definitely won't argue the world is perfect, but it's a whole lot better than 100 years ago. or 200 years ago. or 300...
"The Dawn of Everything" by David Graeber and David Wengrow in part argues, I think quite effectively, that these kinds of statements are based on rather arbitrary criteria of "better" biased on the status quo. There is no linear progress of human cultures that can be assessed with a moral value system, the way we like to see it; it's more complicated.
no generations other than those currently alive had to contend with accelerating anthropogenic climate change at this scale.
No, but in the past, generations have had to deal with plagues that killed off 30% of the population (or 90% in the case of the New World contact), regular famines (less these days, which are now more a political problem than a natural problem) and as always, a high rate of infant mortality. It's always getting better (but not equally everywhere), but at the same time, the problems we do face change.
I vaguely recall that I implemented the trim API in snmalloc, but apparently I never pushed it, and it was probably on my work machine so is gone. It's a bit tricky in snmalloc because the design has a couple of tiers:
There's a global range allocator, which will call notify_not_using in the PAL when a large chunk of memory is unused. On Linux this calls madvise with MADV_FREE if you have a recentish kernel or MADV_DONTNEED on older ones. It took Linux a long time to get MADV_FREE, unfortunately (XNU has a nicer variant, I never got around to upstreaming the FreeBSD version that an intern implemented for me).
But there's also a layer of caching. Each thread owns an allocator, which manages its own free lists (if you free from another thread, it's a remote free and is batched and sent back). A thread-local malloc_trim implementation would return free slabs to the range allocator, but ideally you want malloc_trim to operate globally and that would require some synchronisation that (for performance) is intentionally not there in snmalloc.
I'm not quite sure what MADV_FREE does to RSS accounting on Linux. The semantics are that reads will either return zero or the old contents: the VM subsystem can steal the page at any point and replace it with a CoW zero page. Writes will either do the copy and give you a new zeroed page, or will make the old page no-longer available to steal. I'd expect pages to still count to RSS until they're actually stolen, which means that you won't see RSS drop unless there's memory pressure.
The way that MADV_FREE is normally implemented is that you set a bit in the page metadata indicating that it's in the MADV_FREE state and clear the dirty bit. At some point later, when you experience memory pressure, you look for pages that are in the MADV_FREE state. If their dirty bit is clear, you first make the page read-only, then you check the dirty bit (in case it was concurrently modified), then you update the page to point to the canonical CoW zero page. You hold a lock while doing this that means any racing write will be serialised (when it enters the page-fault handler). This makes putting a page in the MADV_FREE state very fast, but means you don't get precise RSS accounting when there are pages in that state. The XNU version provides an explicit operation to take pages out of the MADV_FREE state. If the page hasn't been recycled, this is very cheap (just clear that bit from the vm_page), if it has then it's a new page allocation. This gives you precise RSS accounting, at a cost of a small amount of performance.
Modern operating systems are optimised for the case where the available memory is large. Running out of memory is an infrequent operation that hits slow-path machinery. Until you hit that case, memory should be easy to use and quick to allocate.
TL;DR: Don't expect RSS to actually be meaningful with a modern allocator on Linux or FreeBSD. RSS is the amount of physical memory that your process can use cheaply. If other processes need more memory, there is some amount between 0 and 100% of a process' RSS that will be reclaimed without swapping.
I did have an implementation on Windows that used the low-memory notification to return pages when memory was low. Unfortunately, Windows doesn't trigger this until physical memory is exhausted. If commit is exhausted but there's a load of physical memory free, you don't get this notification and so it wasn't actually useful.
EDIT: For a while, we didn't use MADV_FREE on Linux because using it came with a pretty noticeable performance impact. No idea why Linux is so much worse than FreeBSD or XNU here.
On Linux, Go's allocator prefers MADV_DONTNEED. It has worse performance characteristics (it's eager instead of lazy, in my measurements MADV_FREE, at least in modern Linux versions, was quite a bit faster), but it actually updates RSS numbers immediately. You can find policies that work with that eagerness to keep the overhead low at the cost of less frequent (but still acceptable, if you consider hugepages as well) return, if you're doing it as you go.
On the one hand you're right not to trust RSS. On the other hand, everyone's monitoring tools trust RSS.
Go has been through a whole saga on this, and this is where things have settled for a while now. It may not be the right trade-off for every project, but made sense there.
It’s on a slow path, so we could probably make it a configuration knob in the Linux PAL (it’s actually templated already, just not exposed for user tweaking easily). Set this way you want it to to work well, set it the other way if you want differently misleading RSS numbers that look better.
This why I wish everyone would implement the XNU APIs.
I am generally of the opinion that languages shouldn't do automatic type promotion and should default to signed integers. Multiplication should always have a result type that is double the width of the operands and should have explicit non-widening versions.
The thing I would like to see more of is Ada-style (Pascal-style?) explicit ranges. Unsigned integers are a special case of this that happens to be easy to represent. But if I know that I'm storing integers in the range [0,100], then I should be able to say that, not just say 'well, it fits in an 8-bit integer and I don't want negative values so I'll pick u8 as the type'. And I want to define wrapping or saturating behaviour, or operations that return larger ranges or require me to put the thing back in line. And the compiler should pick the narrowest machine type that can store the range I want.
Because consistency is really important for people being able to keep rules in their head and if I widen there then I have corner cases. If x is i8, I either don't widen (unless I want to introduce a complex set of integer promotion rules that lead to bugs), so now I have some heterogeneous types that support implicit widening but others that don't. Maybe it's okay to implicitly widen but not change sign, but generally my experience is that this is code where I really want the reviewer to think about the behaviour. Why am I adding a u8 to a u64 here? Why is x a u8, if it's being used in arithmetic with a u64?
In this small contrived example, it's obviously simpler than writing zero_extend<u64>(x) + y, but when I come to review it I can see that this is correct and I can ask 'why does x need extending? Is storing it as a u8 actually saving anything useful?', whereas with the code as you've written it there's some unstated design assumption that may or may not be sensible that isn't exposed.
If I had my way, the promotion rules would be signed can be widened into a larger signed, and an unsigned can be widened into a larger unsigned, but you should not be able to automagically widen an unsigned into a wider signed, nor a signed into a wider unsigned. That should require explicit coding.
Shortening is an issue (going from u64 to u32 or i62 to i32) and should also probably require explit code.
I agree with @spc476 here. I think this is a pragmatic exception to the no-integer-promotion rule: signed widens into larger signed, unsigned widens into larger unsigned. I think it's simple enough that it's easy to keep in one's head. The number on the right side of the type can get bigger, but not smaller.
I do agree with @david_chisnall that it is good to force unstated design assumptions to be stated. It may point out flaws in the larger system, which is extremely valuable. But there must be a middle ground, as after a certain point it can be boilerplate, which increases maintenance cost and cognitive load on readers of the code. Sometimes I just have been given a u8, and a u64, and I want to add them.
I think it comes down to the type of language one is designing. For a systems language like Rust, I think no integer promotion is reasonable. For a scripting language, it is less reasonable. Thoughts?
For a scripting language or, indeed, any application-programming language, I think fixed-width integer types should be for very specialised cases. The default should be a Lisp/Smalltalk-style integer, which is stored in a word if it fits and transparently promoted to a heap-allocated (immutable after creation) big integer object on overflow. The original Smalltalk on the Alto had signed 15-bit SmallInt integers that were stored in a word and anything that didn't fit in this range was promoted to a BigInt. Most 32-bit implementations do 31-bit SmallInts. 64-bit ones often do 61-bit SmallInts and also have inline-in-a-pointer small strings and floats (one Smalltalk vendor noticed that most double values repeat the last bits of the mantissa in one of two ways so provided two types that let you just fill in those bits with a tiny bit of bit manipulation and fell back to heap-allocated values for other floats).
Generally, this impacts performance noticeably only in cases where you could otherwise vectorise things and it's fine to provide specialised limited integer types for things like JavaScript's TypedArray family that let you store big blocks of data that you want to do arithmetic over. If you're doing, say, image convolution, then you have specific overflow behaviour in mind (typically saturating for that one). For the common case, it eliminates a bunch of failure cases and reduces cognitive load (I just know I want an integer, I don't care what kind of integer, representing it efficiently is the compiler's problem not mine).
For a systems language, arithmetic sometimes triggering memory allocation is completely unacceptable, so you do want fixed-sized integers there.
Now here's a question: what if it's a scripting language for embedded platforms? I'm having this issue now and not sure if the Lisp-style int cost (implementation complexity, memory allocation) is outweighed by the benefits (cognitive load, fewer edge cases).
The issue with memory allocation isn't "do we have enough memory," it's "we can't predict our memory needs well". But this could be solved by preallocating enough space for this at startup.
Scripting for embedded is tricky because embedded really wants deterministic allocation so that you know when it’s going to fit. I’ve recently been using Microvium, which is a tiny JavaScript VM that is quite similar to the Smalltalk 80 VM, but it uses a single fixed-sized number type.
The normal thing would be to use double, but a lot of embedded devices don’t have FPUs, so a single integer type and some defined overflow behaviour is probably better.
Object pointers in Microvium are 16 bits (shifted offsets into the heap region, which may be a linked list of allocations: it turns out memory is tight but CPUs are unreasonably fast relative to memory size on most embedded systems), so you probably could do the same thing and promote anything that isn’t a 15-bit signed value. Heap allocation is cheap (bump the pointer) on such a small system and big units are leaf objects so don’t add much GC cost. I’d possibly be inclined to not promote above 64 bits, since most values you need in embedded systems will fit in 64 bits.
The thing I would like to see more of is Ada-style (Pascal-style?) explicit ranges.
Yeah, tho a modern programming language should do it better.
The problem with ranges of that era is they were fixed by the variable declaration. It was easy for intermediate results to bust out of the declared range, and it was inconvenient to relax the constraints within a procedure even if the final result was known a priori to be in range, or if the programmer wanted their own range error handling.
Nowadays it would be better to infer the ranges of intermediate values through arithmetic ops with some abstract interpretation, and allow normal range checks in if statements (etc) to narrow the types. Something like what ATS or refinement or liquid types do, tho I suspect there is a way to provide those kinds of features in a manner that’s more palatable to programmers who aren’t formal methods geeks. TypeScript’s flow-aware type narrowing is a step in the right direction.
What it should look like to the programmer is that arithmetic works in the same mathematically correct manner as bignums, but because the compiler knows the bounded range of all values, it can compile efficiently using fixed width numbers. And comparisons between numeric values should always return mathematically correct results for any pair of types: it isn’t even that hard to correctly compare (say) an f64 and an i64; if the programmer discovers that a correct comparison is too slow they can either use an explicit conversion to throw away some bits, or add a range check earlier to ensure (say) the i64 is within the 53 bit floating point integer range.
And range types eliminate the need for any special case bodges for integer literals: the type of a literal is simply the range covering exactly that value, and there’s no need to work out a more specific type later depending on its context.
Sadly not, I’ve been looking at the literature for the things I mentioned (ATS, refinement types, liquid types) but as I complained, they aren’t quite the shape I want. (Maybe I should wonder over to the university computer lab and chat with the PL researchers…)
Also worth noting sign extension as probably the strongest case against both automatic widening and promotion from unsigned to signed and vice versa.
It's extremely easy to introduce subtle bugs if you don't pay attention to the fact that e.g. 0x70 widens to 0x7770 as a signed byte, but 0x0070 as an unsigned one.
Um ... wouldn't 0x70 widen as 0x0070 regardless? 0x70 doesn't have the sign bit set. It's 0x80 that would sign extend into 0xFF80. From the number you used, I think you mixed octal with hexadecimal. It would be 070 that extends into 07770. I hate that C uses a leading '0' to mean octal.
That problem does not exist under static bignum rules: All you need is correct type inference: The resulting type of each mathematical operation is exactly wide enough to represent all output values.
For addition:
int[A, B] + int[C, D] → int[A+C, B+D]
So that's an invalid program that shall not compile. Slap on the fingers! We get forced to either redeclare i to accept the widening…
var i: int[0, 100] = 90
var i = i + opaque_function_that_returns_an_int()
… or do a narrowing conversion. Note that we don't need a special narrowing conversion: Again, the result of each mathematical operation is exactly wide enough to represent all output values:
var i: int[0, 100] = 90
i = (i + opaque_function_that_returns_an_int()) % 101
That's what we have to do if we are summing unbounded input. Admittedly, the overflow detection is essentially manual:
var sum: usize = 0
var overflow: bool = false
while (…) {
var widesum = sum + opaque_function_that_returns_an_int()
sum = widesum % range(usize)
overflow |= widesum > sum
}
Except that should be solvable with a macro and a Result type. This way, all unavoidable overflow is explicit and must be handled. And we avoid the avoidable. We get a language that is safe yet panicfree.
Hrm, that's true. Does make me wonder how typing would work at some points, though. For instance, how would you type a non-wrapping/non-saturating sum()?
Reminds me of interval arithmetic, if anything, though I'm not familiar enough with the field to say to what extent the benefits/drawbacks transfer, if they do at all.
That's where I want to see explicit type-level choices for this. The valid options are:
Wrapping, in which case, i is 0.
Saturating, in which case i is 100.
Explicit, in which case i++ isn't defined but i + 1 evaluates to a union type of either int[0, 100] or OverflowError (which may also encapsulate the overflow in a type that is guaranteed to support be able to hold the result, such as a BigInt) and each addition must check this condition (or explicitly discard it).
The last one is useful in some niche cases, but the choice of which to use should be part of the type.
LinkedIn is a complete waste of time. It's full of totally unqualified people. You'll get 10x the number of CVs from LinkedIn than from any other source, but you will get maybe half as many that meet your shortlist. Oh, and, if you post a job on LinkedIn, they will add their own submission system, which doesn't ask for the information that the job ad asked for. They also do some 'AI' prefiltering, which is worse than keyword matching.
LinkedIn aside, there are a lot of competent people on the job market at the moment, with the exception of a handful of areas where 'AI' startups are hiring in enormous quantities with enormous salaries. Big tech companies shedding 10-20% of their workforce over a few years means that there are a lot of good people looking for jobs. That means companies can be a lot more selective than normal (from this post: if they want an Elixir developer who is also proficient in TypeScript then they probably have several in their hiring pipeline).
Oh, and if you don't require people to use AI, you get a much better talent pool to select from.
This is less true for companies requiring people to be in the office, unless they're close to one of the big layoff areas.
Those look like pretty good recommendations. That said, I disagree on this one:
Append new enumerators to an existing enum.
That's almost certainly a terrible idea. Modern compilers have a warning if you don't include all enumeration cases in a switch statement. This warning is disabled if you add a default: case, so a lot of codebases omit the default: to make sure that the compiler catches the cases. In these cases, the switch statement will be skipped entirely in code if you actually use the new enum values.
Here’s some friendly advice. In the working world, what marks you as a professional is how you handle situations that are broken. Anyone can remain in control of themselves when things go as expected. But pros stay cool regardless.
Remember: When things are broken, that’s when you get to decide whether you want to be a professional. It’s an opportunity.
Please understand that being a professional doesn’t mean you have to eat crap. It means that if you’re served a plate of crap, you know how to set it aside without drama.
It means that if you’re served a plate of crap, you know how to set it aside without drama.
If you set it aside without drama, then there is high probability that they will serve the same shit, or even more of it, to the next person. To the point where there is just shit.
If you force them to eat it themselves, then maybe there will be some afterthought.
There are ways of telling someone that their behaviour is unacceptable that will make them reconsider it. There are other ways of telling someone that their behaviour is unacceptable that will make them double down on it and disregard your opinion. Part of professionalism is being able to communicate dissatisfaction in the former way. No one can do it all of the time (especially not if they're subject to the same behaviour repeatedly).
There are ways of telling someone that their behaviour is unacceptable that will make them reconsider it. There are other ways of telling someone that their behaviour is unacceptable that will make them double down on it and disregard your opinion. Part of professionalism is being able to communicate dissatisfaction in the former way.
And of course, what "the former way" is exactly highly depends on who you’re talking to. And that’s if they can be made to reconsider at all. How many of us have been taught how to manage their managers like that?
If you set it aside without drama, then there is high probability that they will serve the same shit, or even more of it, to the next person.
No, you're missing something important: In a professional context, drama only makes your message easier to dismiss. Think about the people responsible for a broken hiring process. They don't want to hear that they screwed up. That's a message they will try to set aside. So, if you deliver that message within a bright, blinding opportunity to classify your message as a childish outburst that should be dismissed, rather than an unignorable reality check that must be taken seriously, they'll take the opportunity you have given them.
Which is exactly why it is a waste of time and energy to even try to tell them. Real change requires real consequences for those people. Often, the best way to deliver such consequences when you have no actual power over them, is to tell everyone else.
Often, the best way to deliver such consequences when you have no actual power over them, is to tell everyone else.
Sure, but when you tell everyone else, why wouldn't you rather do it like a professional would? How does it serve the cause to tell everyone in a rant that comes off as childish?
As I said in a sibling comment, that rant didn’t sound childish to me. And to be honest I don’t like the tone policing: most of the time, the most effective tone is not the most polite. It’s something more personal, more direct. Not some corporate friendly writing that sounds like it’s been written by an LLM.
most of the time, the most effective tone is not the most polite.
Nobody said it was. What I said was—let me try to say it in yet another way—that your words are more likely to be taken seriously if you come off as a level-headed professional and less likely to be taken seriously if you come off as a disgruntled candidate ranting with raw frustration. Do you find this claim controversial?
TBH I do not care whether they will change their approach to that. I am describing the pathology of the process. It is up to them whether they will do anything about it.
Again - they did not pay me to review their process. I have no regard about their feelings if they discarded my messages, that it is not what I agreed to. They find it childish - I cannot do anything about it, nor I really care. My own mental health is much more important than what some corporate "thinks" of me, and seeing their behaviour - they didn't value my expertise.
Please understand that I'm trying to help you. I assume you want to land a good job, yes? I assume you want to be taken seriously, yes?
Look, you're obviously smart. If you want to rationalize your behavior, you clearly can come up with all sorts of justifications, but I'd ask you to consider whether there's some truth in what I'm trying to tell you.
I'm going to try one more time.
Again - they did not pay me to review their process.
Doesn't matter. What does matter is how your behavior—during the interview, when you wrote about it on your blog, and when you doubled down on it here—shapes the world's perception of you and how that perception helps or hinders your pursuit of your goals and dreams.
I think you want to be perceived as a serious person, a professional that any top company would be delighted to add to their team. If so, the questions you ought to consider are: Does your behavior, your very visible behavior, argue that you are a professional and that hiring you would be a great idea? Or does it argue that you have questionable judgement and that even interviewing you is a risk that could blow up on them?
I have no regard about their feelings if they discarded my messages, that it is not what I agreed to.
Your duty to be a professional is not conditioned on their behavior. It's a promise you make to yourself and to society. Again: It's not conditional on their behavior. If they disrespect you, that's not license to disrepect them. You always treat other people with respect because that's what a professional does.
They find it childish - I cannot do anything about it, nor I really care.
Do you seriously believe that your behavior has nothing to do with how others perceive your behavior? It's not just that the people involved in this broken hiring process find it childish. I'd estimate that approximately 100% of people in a position to hire you would find it childish. Do you care about landing a good job? Then you ought to care about how your behavior reflects upon you.
My own mental health is much more important than what some corporate "thinks" of me, and seeing their behaviour - they didn't value my expertise.
Of course your mental health is important! But there are other ways of opting out of a broken hiring process than behaving in a way that makes it harder for other companies to hire you. Being a professional doesn't mean you have to be a pushover. It just means that when you opt out, you do it like a professional. And doing it like a professional means firmly but politely withdrawing your candidacy, not writing a rant about it on your blog, and not doubling down on your rant when people try to helpfully point out how your behavior is likely to reflect upon you and affect your career prospects.
We aren't lawyers. Our professionalism is rooted in the quality of our advice, not our workplace conduct or adherence to some bogus creed. The reason to keep a cool head is to avoid offending management. The reason to keep language polite and neutral is to avoid hostile-workplace lawsuits. We aren't suits or squares.
(I'm going to reply in earnest and assume you aren't trolling.)
Our professionalism is rooted in the quality of our advice, not our workplace conduct or adherence to some bogus creed.
This claim defies what the public and members of most computing-related professional societies expect of professionals. In short, your professionalism should carry through to everything you do: not only the quality of your advice but also your conduct. Consider, for examples, the IEEE Code of Ethics, which states that, "We ... do hereby commit ourselves to the highest ethical and professional conduct..." and the ACM Code of Ethics, which requires members to "Maintain high standards of professional competence, conduct, and ethical practice." (Emphasis mine)
The reason to keep a cool head is to avoid offending management. The reason to keep language polite and neutral is to avoid hostile-workplace lawsuits.
I'd say that the reason to keep a cool head and to keep language polite and neutral is that that is what is expected by the public of professionals. The reason it is expected is that to be hot-headed, impolite, or biased in professional communications increases the chances for mistakes and misunderstandings, and in engineering contexts mistakes and misunderstandings can have serious consequences.
I’m not sure, but I’d expect some examples, some of the corner cases, and so on. The one-liner of ‘ABI changes mean you must recompile a dependency for it to keep working, API changes mean you must modify the source for it to keep working’ gives you about as much information as this.
This is interesting to me as well, understanding what an API is very well but barely having had the need to understand what an ABI is, or the problems with an unstable or incompatible ABIs. It's been one of those background questions I had simply left wanting for the time an explanation shows itself to me, like this post here :)
Bryan has mentioned that he dislikes epoll. From his prospective it’s an api that’s hard to hold and can cause heavy cognitive load on the consumer. It’s a “good enough” api when compared to kqueue
There’s some podcasts with the bsd cast where he mentions it but I can’t find the episode right now.
Another concern was along the lines of the parents getting stale messages from a child that dosent exist (verify this because it’s off the top of the dome)
I don't think that's relevant here. A similar bug would be fairly easy to introduce with kqueue. The back end of both look quite similar, it's just the user-facing interface to epoll that is awful.
I really wish the Capsicum for Linux effort hadn't been killed by NIH. It's a far better model for sandboxing desktop applications (launcher grants them a set of initial capabilities [file descriptors] based on their metadata and they can't access anything else, powerboxes provide capabilities for opening and saving other things) than the pile of things that are used in Linux to try to achieve the same thing.
The whole Linux container model is a kinda scuffed patchwork of concepts that align mostly with running something akin to kubernetes services where services are orchestrated by some god-process, but don't really fit in a desktop environment where you'd want the ability to enter a lower privilege cgroup/namespace from userspace without going through the sort of root daemon or setuid rigmarole that inevitably invites privilege escalation risk.
It's also the wrong abstraction. The container isolation model is similar to jails in FreeBSD and Zones in Solaris: they're isolated worlds that look like VMs, you get something that's close to a separate computer. The thing I repeat all the time:
Isolation is easy, sharing is hard
The hard bit for application sandboxing is that it isn't an isolated environment. A sandboxed app that I run wants to have access to a document that I ask it to open, but only after it pops up a dialog box and I select the file, and only until the program quits. I want it to read from the clipboard, but only after I either use a standard keyboard shortcut (which the windowing system can intercept and grant access to the current clipboard contents before forwarding the event).
These very dynamic things are the kinds of things Capsicum was intended to support. You can start with access to a socket that talks to the windowing system, maybe access to a GPU device context, access to a temporary directory that is specific to this run and will be cleaned up at the end, read-execute access to shared libraries, and so on.
In theory this is how the major Linux desktop sandbox tools (Flatpak etc) are supposed to work, with SCM_RIGHTS + Wayland + D-Bus acting as the primitives. You can sort of see the outline of a secure desktop if you squint.
But the actual implementation on all sides is some combination of overly permissive, inflexible, and half-broken. Nobody seems to care about securing it end-to-end in the same way that people care about securing server workloads, which is why gVisor and Firecracker work so well but Flatpak can't even run a basic Gtk+ application without breaking the fonts, and every Wayland compositor has to re-implement half of the trusted desktop base.
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in, while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic. Just do what they do! Why the hell is anything in the window manager reading /proc/{pid}/cmdline ??
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in,
Kind of. Android apps have a far simpler model for sharing (and some big holes when you try to make it look more like desktop interaction models).
iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic
Capsicum was designed, with input from Apple folks, specifically to support the sandboxing models that OS X shipped. They didn't switch to it because they'd already built something that did 90% of what they wanted on top of the TrustedBSD MAC layer and rewriting the whole thing with Capsicum was not desirable by that point.
while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic. Just do what they do!
..are we talking about the platforms that don't even allow to access filesystem ? For actual serious apps it's a constant pain in the ass for the end users and usually the basic answer to "the app i downloaded cannot find the files I need to do my work but I see them in my Documents" is "use another OS". Yay for highly ergonomic.
..are we talking about the platforms that don't even allow to access filesystem ? For actual serious apps it's a constant pain in the ass for the end users and usually the basic answer to "the app i downloaded cannot find the files I need to do my work but I see them in my Documents" is "use another OS". Yay for highly ergonomic.
I use all three platforms (Ubuntu workstation, macOS laptop, Android mobile) and the macOS sandboxed apps are fully capable of accessing files. They use a mechanism similar to the XDG "portals" from Flatpak.
The major behavioral difference is that they need to be granted permission to access those files, so when I open up a document editor I have some assurance that it's not going to exfiltrate my SSH keys.
Nobody seems to care about securing it end-to-end in the same way that people care about securing server workloads, which is why gVisor and Firecracker work so well but Flatpak can't even run a basic Gtk+ application without breaking the fonts,
I feel like these are measuring very different things? The scope of firecracker in particular is far narrower, given that it's "just" a micro VM implementation—not to discount the effort it takes for that, but Flatpak is trying to wrangle an existing and very complex ecosystem, whereas firecracker is doing a very good at mixing together two singular existing things (containers and VMs) and building on top of that existing infra. gVisor is certainly much much more involved, being basically a userspace kernel, but that's more practical when it's backed by Google money.
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in, while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic.
...both of which are also backed by big company money and have the privilege of being able to tell the developers within "lol, cope" when making the necessary breaking changes. Linux userspace does not have that luxury.
Just do what they do!
Both of these mentioned have more tractible sandboxing because it's intertwined with the application platform. Linux userspace also does not have that luxury.
The scope of firecracker in particular is far narrower, given that it's "just" a micro VM implementation—not to discount the effort it takes for that, but Flatpak is trying to wrangle an existing and very complex ecosystem,
Flatpak has a much narrower scope than either Firecracker or gVisor, in that it only needs to provide a capability-passing mechanism on top of existing well-defined primitives.
Flatpak should not try to wrangle an existing complex ecosystem, because that's what makes it insecure. It ought to define a secure API and then require applications conform to that API to be used in its sandbox.
...both of which are also backed by big company money and have the privilege of being able to tell the developers within "lol, cope" when making the necessary breaking changes. Linux userspace does not have that luxury.
Flatpak is also backed by big company money (IBM).
Given that a breaking change vs POSIX is required to get capability-based sandboxing, Flatpak has the option of telling developers "if you want to be run in Flatpak then you need to use these new APIs for sandboxing". Right now it's telling users "lol, cope" when they want to sandbox applications running on their machine, which is how you end up with articles like this link.
Both of these mentioned have more tractible sandboxing because it's intertwined with the application platform. Linux userspace also does not have that luxury.
You don't have to handle arbitrary Linux binaries. The set of APIs needed of a typical desktop application is much smaller than that of the entire Linux kernel, and (just like in macOS) users have the option of installing an application outside the sandbox if they really want to.
At present Flatpak's approach is to pretend to sandbox applications while allowing them to retain nearly complete access to the host system, and the user doesn't have the option to restrict applications other than rebuilding them. That defeats the entire purpose of a sandboxed application distribution platform (where the user should not need to trust the application to be well-behaved).
Flatpak has a much narrower scope than either Firecracker or gVisor, in that it only needs to provide a capability-passing mechanism on top of existing well-defined primitives.
I'm admittedly using "Flatpak" quite loosely to include stuff like the XDG portals in here, but yes as mentioned below, a brand-new shiny capability-passing mechanism would simply have been used by nothing. The difficulty in Flatpak + portals is making something that's usable without as much manual changes to critical areas (e.g. the file chooser portal exposes files over FUSE, because then the application can treat them afterwards like usual), and trying to match the byzantine complexity of host-side configuration when required (for stuff like fonts and graphics drivers).
Flatpak is also backed by big company money (IBM).
Ah yes the entire active maintainer team consisting of checks notes a single person.
Given that a breaking change vs POSIX is required to get capability-based sandboxing, Flatpak has the option of telling developers "if you want to be run in Flatpak then you need to use these new APIs for sandboxing".
If this happened, Flatpak simply would have never reached any adoption. Getting anything major done in the Linux desktop world is like pulling teeth, and Flatpak's wider use is a relatively recent phenomenon. Lots of projects did not even have portal support for a very long time, and many of those additions were external volunteer efforts.
which is how you end up with articles like this link.
This link is entirely a KDE-side bug, by this logic the multiple fatal bugs in Pixel hardware decoder drivers are a failure of SELinux. No sandbox is going to save you from exploits at a higher level, and Flatpak already provides ways to tie an arbitrary PID to the enclosing sandbox / app.
At present Flatpak's approach is to pretend to sandbox applications while allowing them to retain nearly complete access to the host system, and the user doesn't have the option to restrict applications other than rebuilding them.
I genuinely don't understand what "nearly complete access" is referring to? All static permissions can be changed with flatpak override or flatseal. Dynamic permissions are only granted as requested and gated by portals (and can be manually overridden). If you want VM-level isolation...well macOS and Android don't go that far either, do they?
Flatpak is also backed by big company money (IBM).
Ah yes the entire active maintainer team consisting of checks notes a single person.
If IBM wants to hire more maintainers for Flatpak then that's well within their ability. Google spends more on gVisor than IBM spends on Flatpak because Google values having a secure sandbox for executing untrusted code, and IBM doesn't seem to.
a brand-new shiny capability-passing mechanism would simply have been used by nothing
I think this is the main point of disagreement. A capability-passing mechanism would have been useful, and may have been adopted to enable distributing Linux desktop applications with the same simplicity as Android or iOS applications. Eventually there would have been a split where easily sandboxed applications get distributed with a Flatpak-like mechanism and applications that don't fit the sandbox model still get distributed with Apt or whatever.
Instead we end up with Apt providing unsandboxed installation, and Flatpak providing insecure sandboxing, so there's no reason to use Flatpak.
Building an application distribution that doesn't have effective sandboxing doesn't provide much value over existing solutions (Apt, Docker / Podman, tarballs) so there's no incentive to adopt it.
I genuinely don't understand what "nearly complete access" is referring to? All static permissions can be changed with flatpak override or flatseal.
The last time I tried to use a Flatpak-distributed application (Gimp) it installed with full filesystem permissions. Looking at https://flathub.org/en/apps/org.gimp.GIMP there's a list of permissions it wants, which includes both "Full file system read/write access" and "Network access".
That level of capability either shouldn't exist (as in macOS / iOS) or it should require explicit user opt-in, instead of requiring the insecure application to be installed first and then manually fiddled with via obscure command-line tooling. If I'm going to open up the command line anyway then I might as well just run it in a proper sandbox with waypipe.
I'm not sure if Capsicum is good though. I looked into it a while ago as part of figuring out how to get some form of first-class sandboxing in Inko (using OS primitives, so Capsicum on FreeBSD, Landlock on Linux, etc). From the top of my head the big issue with Capsicum is that you need to create all the necessary file descriptors ahead of time, but you can't always do that. FreeBSD's approach to making this more manageable is libcasper, but this requires you to explicitly write your code with that in mind (i.e. instead of calling foo() you'd have to call the casper_foo() equivalent, if one exists to begin with).
Perhaps unsurprisingly, Capsicum doesn't see much use from what I know. For example, from what I remember both Firefox and Chromium don't do sandboxing on FreeBSD because of how frustrating/limiting the Capsicum API is. On OpenBSD I believe at least Firefox uses both pledge and unveal, not sure about Chromium.
The better API to copy is probably pledge and unveil from OpenBSD, precisely because they are simple enough to use so people actually want to use them while still being good enough for most cases. Unfortunately Linux seems stuck in this repetitive pattern of introducing very low-level and verbose and clunky to use APIs instead, with even Landlock being kind of a pain to work with.
UNIX domain sockets can carry new file descriptors, so it’s easy to have a more privileged process pass file descriptors. We had a demo almost 15 years ago of Qt patched to make open and save dialogs run in a separate process and return new file descriptors. Unfortunately, because the internal APIs all work with strings, this was quite hacky to make non-invasive (the strings carried the FD and propagated it during path manipulations. A sandboxing-friendly API would have the file dialogs return file handles).
Google rejected the Capsicum patches to Chromium for the same reason that they rejected all of the other FreeBSD patches: they don’t take patches to support targets Google doesn’t ship Chrome for. The Chromium team were the ones pushing for Capsicum for Lin though, because the sandboxing layer was significantly less code with Capsicum than with anything else.
The thing I would really like is bidirectional sync of PRs and issues with GitHub. The most painful thing about migrating is that it’s a flag day. Before the migration, you’re telling everyone to use GitHub. After migration you’re telling everyone to use the new thing. It’s like moving house: you always want a mail redirection for a few months so people who don’t know you’ve moved can still reach you. I would love to phase it as:
Read-only migration. Code, issues, and PRs are mirrored to the new thing, but can’t be edited there.
New things is the default but GitHub still works. PRs can be opened in both places and are reflected in both, comments are copied across.
GitHub issues are made read-only PRs are automatically closed with a ‘please open in the new place’ message. Code is mirrored back to GitHub.
GitHub project is archived with a not about its new home.
Without that gentle flow, there’s an abrupt transition that makes it painful.
Once you have migrated, the main thing I want is something that can import GitHub Projects for project management.
Bidirectional sync of PRs is mostly an anchoring problem, which is why nobody has shipped it well. Issues mirror fine because they're text with stable ids. Review comments are anchored to file + line + commit, and the moment someone force-pushes or the two forges compute the diff differently, every anchor drifts. GitHub's API makes it worse by exposing comment positions relative to the diff hunk rather than the file. Any forge that wants the gentle migration path you're describing probably has to store review comments against something more stable than line numbers, then project them onto whatever diff each side renders.
Cool project! If my team were to switch we'd need:
Issue tracker with labels and API (but it seems you are targeting this)
Branch rules, and protections & integration with CI/CD
Actions i.e. CI/CD (It would be great if you could bring your own cloud provider for this)
A nice PR review UX (should be doable to beat GitHub at this since their UI is actually noticably regressing...)
EDIT: One thing that would really help is an "Import from GitHub" button to smooth over the transition. Though it seems technically pretty hard to do it for code, PRs, issues, actions, etc.
We use GitHub issues and Projects for private repos. We’re starting to use Linear because GitHub doesn’t make it easy to track issues that span multiple repositories that are public and private and get the planning views, but if a F/OSS GitHub alternative eliminated the need for Linear then that would make me very happy, especially if they offered a hosted option that I could just throw money at. Oh, but not if it’s one of these bullshit ‘open source, but the features that are essential to corporate use are proprietary’ things: I want a F/OSS thing so that there’s an easy second source if you go evil, if the features I need are proprietary then your going evil is a migration anyway and you’re just another SaaS provider that looks like it’s planning a rug pull.
JIRA should be used only between consenting adults, in private.
make it easy to track issues that span multiple repositories that are public and private and get the planning views
For cultural reasons I haven't seen it used in anger but I would be shocked if GitLab's issue tracker doesn't support that since they have first-class support for hierarchy:
That "actions" one has some nuance since of course the .yml come over for free, and would need analysis to convert to your new CI setup's mental model, but I actually don't see the CI secrets mentioned in that imported-data list. However, that's a gap in the automation and not "technically pretty hard"
I find the timing of these frustrating because they always come just as we complete a hiring cycle. We’ll be hiring more people in a few months and I fully expect that will also not line up with one of these posts.
Be the change you want to see in the world. I don‘t know how it will be received / moderated, but it is worth a try and probably without consequence if it goes wrong.
But in this case, the government will have to approve the OSes and browsers that are legal, right? Because if I can just download an other browser on my computer and visit any site, it doesn't help much. I find the much more dangerous.
It's reasonable to expect a social norm that parents should not give their children administrative permission over their devices in order to install another browser. On mobile devices, which are overwhelmingly the most popular platform for youngsters by my understanding, that's probably actually good enough. On desktop, portable browsers easily get around this and we can expect kids to start learning what those even are quickly enough, but they come with their own inconveniences and that kind of intentional rulebreaking behavior is a perfectly normal part of growing up that we shouldn't be expecting to defeat through technical means. Just make it a crime to market a browser for this purpose and you defeat the economic incentives that would otherwise lead corporations to drive kids toward that behavior for reasons other than natural curiosity or rebelliousness.
No, not at all, any more than a DVD player must be government authorised and will refuse to play DVDs with a certain rating without a government-issued token.
We put age recommendations on DVDs (and VHS tapes before that) so that parents have the ability to make informed choices about what their children watch.
If web sites that provide adult content are required to provide headers that specify the kind of content, browsers are entirely free to ignore them, but parents are also able to set up their children’s systems to use only browsers that reject pages with certain things in the headers.
If Facebook has to send X-Parental-Guidance: AddictiveAlgorithm FarRightRadicalisation, it’s up to parents to decide whether to allow their children to install arbitrary software on their device and, if not, to define whether this is something that their browser must respect.
There's a lot of things the government can do. They can sponsor and mandate proper protection on children's devices. Create a free parental control software. Create awareness programs so that it becomes the default among children. Ban devices in schools. Fine parents if children are caught with unblocked devices.
Notice how none of this takes the adult's freedoms away.
Anyways, I'm pretty sure with the current trend and modes of thinking, we will end up with both the government-approved devices, and the digital passports that will be required for everything, from filling taxes to buying toilet paper.
Well, fining parents if children are caught with unblocked devices does take away a parent's freedom to trust their child. Broadly speaking, though, yeah - trying to centralize identity management like this is so completely unnecessary to achieve the stated policy goal of empowering parents to protect their children that that can't be the real motivation.
EDIT: Realizing that may have come off as more of a vague accusation than I intended, I'll be clear - I think the real motivation is to implement the control over what all children can view that the concerned parents want exerted on what their own children can view. I don't think most reasonable people supporting this sort of thing actually want the surveillance state it creates, they're just willing to accept that as a cost of protecting their children, though I think it will fail to do that and still create the surveillance state.
This is anonymous, even if the government and the age-checker collude, there is no way to correlate the identity and the session. It's how a zero-knowledge proof like zkSNARK works.
Now, if you mean the government is giving a backdoored wallet that does not do what it says it does, yes, it can. But you don't have to use the govt-provided wallet either, they have published the source code on GitHub.
Do you have a citation for this claim, because absolutely nothing that I’ve read about this algorithm class suggests that it is secure in the presence of collusion and communication via out-of-band channels. In particular, each token that the age checker generates is unique and it’s trivial for them to share a mapping between that token and identity with a third party.
In fact, I don’t believe it is possible to design a ZK scheme that has the desired property. Either each attestation is unique (or is a member of a small set), in which case deanonymisation in the presence of collusion is trivial, or attestations are not unique, in which case they are trivially forgeable.
I see, so that includes a random factor that means that you can't tie new proof to the original attestation, but you can still check the property. But if the attestation leaks (e.g. security vulnerabilities in the wallet), you can regenerate every proof that the wallet has generated?
That's somewhat less bad, though I still strongly disapprove of moving parental decisions to someone else's control. We set the correct precedents when home movie rental came along, we don't need to do the opposite now.
Just a thought: What if we made online platforms liable for harm to the people? What if they were responsible for all the hate, misogyny, and radicalization?
If the platforms stopped hosting all of the content, if they stopped optimizing for engagement/rate bait to maximize clicks and ad engagement - maybe the internet wouldn’t be so fucking harmful for people out there (not just kids. Everyone.)
If we made online platforms liable for users' harms, all small, non-profit social spaces, including this one, would disappear in a year or two. The US's Section 230 protects independent communities because it "creat[es] broad immunity that allows the early dismissal of many legal claims" rather than being a defense subject to ruinous, draining litigation. If every coffeshop was liable for harm done on its premises, dumped lovers would bankrupt everything smaller than Starbucks. You would see less harm in the same way that paving over a playlot results in fewer injured children.
If we made online platforms liable for users' harms
I think there is a difference between:
"liable for [any] users' harms"
"liable for [consistent, massive] users' harms"
I am consistently disappointed to hear/read people concluding that "f(x)" is an inconceivable solution to a problem because when x is very large bad things happen.
Just put boundaries on x then and see things get better.
Obviously this is a simple metaphor, but I think it gets the point across.
I think more broadly, people should start accepting that imperfect solutions are valid when not doing anything is clearly worse.
Yeah, it’s true that I wouldn’t want this to happen. My thinking was mostly derived from a European perspective, where people don’t sue "all the time" and there’s more onus on the accusing side.
I don’t think it would immediately have to result in this kind of situation you’re describing (and we both don’t want). I don’t want to debug legal ideas in lobste.rs threads, but I could envision different rules depending om platform size and media types (text forum vs images vs videos…).
What if we made online platforms liable for harm to the people?
Online platforms have carve-outs for liability, e.g. Section 230 of the Communications Decency Act of 1996 in the US (and similar elsewhere, but that one is the blue print many of the others are based on.)
It might be useful to reconsider what constitutes such a platform: The idea is that because they're merely providing user generated content, they're not responsible - as long as they delete harmful stuff once they're told about it.
Is that still the case when their feed algorithms decide what is shown? I'd say that an editorial decision like that (no matter if made by a person or an algorithm) should come with editorial responsibilities, too.
Section 230 was based on common carrier laws. These made sense: the postal service is not liable for the contents of parcels it carries. If you send illegal drugs via the post, you are 100% liable, not the post office. The same applies to the telephone network. If you plan a terrorist act over the phone, the phone company cannot be charged as a conspirator.
Common carrier liability exemption comes with a legal requirement that you must be neutral. You must carry any parcel / message / whatever without reference to its content. You may not prioritise messages based on content (you can charge more for heavier parcels or for faster delivery, but you must make those charges uniform).
I am completely happy with the common carrier rules.
But the ad platforms like Facebook and X are not common carriers. They are publishers. They choose what to amplify. They block people who have not violated any law. They should be liable for any illegal or harmful content that they distribute.
But the ad platforms like Facebook and X are not common carriers. They are publishers. They choose what to amplify. They block people who have not violated any law. They should be liable for any illegal or harmful content that they distribute.
That's what I'm saying. The feed is on them, but they hide behind "that counter-point to the anti-democratic deluge we're putting in front of everybody is just as accessible - if you know and bother to access it directly" to pretend that they're still common carriers. Hitchhiker's Guide, basement, leopard, something something.
I don't think it's correct that Section 320 was based on common carrier laws. I haven't seen it in what I've read of the contemporary debates or records like Kosoff's. The Telecommunications Act of 1996 that included Section 230 classified the internet as a Title I "information services" rather than a Title II "common carrier services". The reclassification didn't start until the FCC's Open Internet Order in 2015.
The explicit goal of 230 was to avoid the consequences of Stratton Oakmont that held Prodigy liable for user content because they had moderated. You can read it in the Congressional Record at the introduction of the Cox-Wyden amendment that became Section 320. It is very specific and prescient:
The court said, ``No, no, no, no, you are different; you are different than CompuServe because you are a family-friendly network. You advertise yourself as such. You employ screening and blocking software that keeps obscenity off of your network. You have people who are hired to exercise an emergency delete function to keep that kind of material away from your subscribers. You don't permit nudity on your system. You have content guidelines. You, therefore, are going to face higher, stricker liability because you tried to exercise some control over offensive material.
This description is the exact same argument @freddybposted (and I replied to). If liability is imposed on internet communities as advocated, expect any surviving American internet communities to be bleached of any topic or opinion considered too complex or inappropriate for a preschooler in the most socially restrictive social group of the country.
But the solution there is not to repeal Section 230, but to improve it. Yes, repealing Section 230 would allow us to hold Meta, Twitter, YouTube, etc. liable, but it would harm everything else - including the sites we're discussing this on!
It only needs to be applied: Just reconsider if Facebook, Instagram, X, YouTube, ... are platforms or, simply by virtue of their editorial decisions, publishers.
The platform part can remain protected as platform as usual. The algorithm doing the "publishing" (i.e. front page, personalized feed, ads etc) and its output? Editorial control → editorial responsibility.
I don't even really know where to start with how much is wrong in this post.
No, Section 230 is not based on common carrier laws. Section 230 is based on an extremely broad conception of the 1st Amendment to the US Constitution, and on a strain of legal thinking that is repulsed by the idea that people might be punished for speech.
No, Section 230 does not care about "platform" versus "publisher" distinctions. Section 230 does not require that a site or service be neutral. Section 230 does not require that it be unbiased. Section 230 does not require that it be fair. Section 230 does not require that it be consistent. Section 230 does not even require that they try to do any of these things.
If I wanted to set up a forum and openly arbitrarily ban anyone or remove any post I don't like, at any time, for any reason including my inconsistent personal whim and mood at the moment, I would absolutely not be acting like a common carrier, but I absolutely would be protected by Section 230.
And that ultimately is the backbone of much of what we now take for granted about the internet. Without it, sites like this one simply would not exist, because the existence of moderation rules on this site would, under the prior Prodigy precedent, make the site be potentially legally liable for the contents of any posts the moderators choose to leave up, and the only safe way to play that game is not to leave up any posts at all.
This is a debate that has been going on for a long time over section 230 in the US. In short, the has US opted to treat online platforms as neutral carriers, like a phone company, rather than as publishers like a newspaper. If a newspaper publishes a libelous article, they are legally responsible for it because they have exercised editorial control. On the other hand, if a person says something slanderous over a phone line, we don't hold the phone company legally responsible because they are a neutral carrier, they just get your sound waves from here to there, they don't have editorial control. Treating the internet and online discussion boards as neutral carriers rather than publishers was one of the key factors that enabled forums and social networking sites to exist in the first place without the fear of being sued into oblivion for something a random member did before a mod got around to banning them.
Particularly for large platforms like YouTube, Facebook, Instagram, etc, it is logistically impossible to have a human vet every comment or private message or video. So the only feasible path forward if you held them liable for users' content on the platform would be to move away from an open internet with user content and towards a smaller number of vetted content producers and mass automated censorship, which would still not be adequate to prevent people from circumventing it or drawing people off-platform to be further radicalized.
The one area where I think the legal framework of "neutral carrier" is a bit less plausible is algorithmic content promotion. We know that companies with recommendation algorithms are doing a lot of subjective judgement calls about which content they want to promote and which content they want to bury. A Facebook feed that displays your friends' posts in chronological order is acting as a neutral carrier. A feed that uses a carefully designed algorithm that selectively promotes one political viewpoint over another or even one emotional vibe over another is starting to look a lot more like a publisher with editorial control than a neutral carrier.
They should be. I think that you only have social media platforms in mind.
There are online services and platforms that are not illegal, they just aren't suitable for kids. Betting sites for example. Or content that is just not appropriate for a 9 years old. There are many cases where as a parent you have to say, "no, this is not for you yet", and more and more of these cases are online in the last decade.
content that is just not appropriate for a 9 years old
And who's going to decide what that is? The parents, who might be against the child's sexual orientation for completely invalid reasons? The politicians, who represent the parents more than they represent the kids? A 9-year-old LGBTQ kid should be able to find relevant content regardless of what their parents think. The Internet is possibly the best tool we've yet invented for liberating kids from their parents and other local authorities (self-appointed religious authorities for example). Let's not take that away from future generations.
While I agree with your goals, I don't think I agree with your points. You are asking the question but it needs an answer! Who will decide what is good for the kids when they cannot do that for themselves yet? You seem to suggest that the answer is "nobody" but while I have no references, I am pretty sure that is scientifically wrong.
Since no authority can be reliably trusted to decide what's good for kids, I think I'm willing to accept some harm in order to ensure that marginalized kids find what they need. But let's kill the worst of the harms, for everyone: the addiction loops, gambling mechanics, and algorithmic radicalization.
In EU countries, we generally agree that there are authorities that decide if our kids are fed properly, if they go to school as the law demands, if they are neglected, at what age they can drive, and buy tobacco, if they are allowed to carry guns, and many other things.
Maybe where you live is different, but remember, this is an EU directive, and it only applies to EU, so it probably doesn't affect you.
The EU "cookie law" affected my experience of basically every commercial website I go to. That is a minor annoyance; restricting traffic has much graver consequences and therefore demands much higher (IMO, insurmountable) standards.
True, like smoking, not everybody dies of cancer and some people really enjoy it. So clearly, for some people smoking is a net positive and science cannot answer the question for whom.
One would think so. But then, giving kids such ideas could deprive "authorities" (such as parents) their God™ Given Right to exert discipline (behind closed doors), so who knows what happens when the 39% (to pick a number from a 2020 US study) "who had positive attitudes toward physical punishment" get in charge…
Good thing that it's not up to their parents in this case. Any decent country (and I would argue EU countries, with all their faults are decent) would make ensure that these types of online services and resources are not age limited.
I would bet that ALL EU countries already have phone lines where a kid can call and get help from experts, no questions asked.
Keep in mind that this infrastructure is usable by anyone, not just people who think like you. Do you trust the definitions that Afghanistan would come up with? China? Pakistan? North Korea? America? Pick any other actor you want here.
Well, a betting site requires you to pay money or connect a payment system upfront using a working bank account. I would guess that's a great age verification tool right there.
There's a difference between the parents saying it and some random enforcement mechanism that sends data to whomever.
Compliant sites can already provide guidance via https://rtalabel.org/ and have "parental control" enabled devices enforce it. Non-compliant sites¹ wouldn't bother collecting age information anyway.
There used to be more fine-grained schemas for age / audience appropriateness, but they languished. Could still be brought up again: have the data tell who is supposed to read it, then make the client make the decision.
¹ since you brought up betting sites: gambling is huge on the "ignore the rules" side of business
Most parents if not all, are even less aware. If you have teenage kids, you know that (if you're lucky, and if you're capable, and if you do have a good relationship with your kids) you have to learn about a lot of online "dangers" that never crossed your mind before.
This is the equivalent to saying that in the physical world, just label it ALCOHOL, ADDICTIVE, TOBACCO, and leave it up to the parents to decide if their kid is allowed to buy it. Parents have a huge responsibility, but they also need help.
If you check the EU blueprint, thy mention other, more fine grained attestations, but this out of the focus of my post.
Yes, betting sites have huge incentives to ignore legislation. This doesn't mean we don't have to add friction. The usual argument (which I also support) is that adding some friction by introducing huge privacy risks is not worth it. But it seems that in this case, privacy risks are very low to zero.
This is the equivalent to saying that in the physical world, just label it ALCOHOL, ADDICTIVE, TOBACCO, and leave it up to the parents to decide if their kid is allowed to buy it. Parents have a huge responsibility, but they also need help.
There are a few crucial differences between "physical" and "digital". The biggest for this question: in the physical world, "move" is free and "copy" is not while in the digital world, it's exactly the other way around ("move" is typically "copy + delete"). This means that when I present data in the physical world, the inspector (e.g. the cashier in the store that checks if I'm old enough to buy alcohol) would have to go through extra trouble to note down the information they received, while on a website, they have to go through extra trouble to "forget" the same information.
Yes, betting sites have huge incentives to ignore legislation. This doesn't mean we don't have to add friction. The usual argument (which I also support) is that adding some friction by introducing huge privacy risks is not worth it. But it seems that in this case, privacy risks are very low to zero.
The accessibility risk remains rather high, though. Your "digital" example starts out with "An authorized issuer verifies your age once and issues a signed credential:"
If your local government refuses to give you a certificate you are entitled to get, then there are laws, and at least you know who to shout at.
What you describe is not much different than saying "and what happens if they refuse to give me a driver's license" in order to argue that anyone should be allowed to drive without a license. I respect if you believe there should be no government at all. That's practically what the intro says "If you think age verification should not exist at all", the rest of the discussion is pointless.
If your local government refuses to give you a certificate you are entitled to get, then there are laws, and at least you know who to shout at.
The German government recently proudly announced some driver's license app. It only works on "verified" devices, and they see no reason to change it.
Now, that's not a problem for driver's licenses, as long as the default is the plastic card thingy. But a friend of mine has an unlocked smartphone. I don't have a smartphone at all.
At 90% (or 95%, or 99%, doesn't matter) market penetration, they might well decide that having the app on your phone, talking to the car via NFC ought to be mandatory to track that only authorized folks can drive a car. For safety.
But what they really enforce is that you have a contract with Apple or Google.
A big problem in all that is that the politicians who drive such initiatives aren't exactly digitally literate. And as long as digitally illiterate busybodies like v.d.Leyen have a chance to perculate up the political food chain (she's big on the "think of the children" arguments and infamous for making a mess with her insistence that things go her way), I'm not interested in them having any say on how computing is supposed to work.
Separate reply for separate tangent: Websites can set up labels that aid parental control systems, and your claim is that this doesn't work because "most parents are not aware."
So you're assuming that kids will get devices that are, in some way, running an adult account, and not using Apple's Parental Controls, Google's Family Link, Microsoft's Family Safety or any other such mechanism.
What makes you think that these "unaware parents" won't just add their "I'm an adult" credentials to the account to make any complaints go away, either (or reuse their personal adult account on the kid's device. Or share the device, with no account separation - both of which amount to the exact same outcome)?
Basically you're arguing that parents are both too naïve to set up protections for their kids and savvy enough to set things up correctly for the age verification to verify their kids and not themselves.
Sure, you can do this. Every approach has its pros and cons.
I would love to see a comparison table between an attestation-based solution and a device-based solution.
One thing that I consider important is that a device-based solution depends on any OS working according to some guidelines, which favors the big established ones, both on mobile and desktop. An attestation-based solution places little to no burden on the OS and apps, which I prefer for various reasons.
One thing that I consider important is that a device-based solution depends on any OS working according to some guidelines, which favors the big established ones, both on mobile and desktop. An attestation-based solution places little to no burden on the OS and apps, which I prefer for various reasons.
Attestation-based solutions depend on the attester trusting your OS and app, and they will be content supporting a "some-9s" amount of platforms and ignore the rest.
Device based solutions depend on the parent making a choice that suits their parenting style, with the default options (that tech-illiterate parents would gravitate to) offering robust configurations out of the box.
For that reason I kinda suspect (with anecdotes supporting my suspicion) that building client-side restrictions places fewer burdens than having to appease some semi-central authority that has no interest in talking with you.
You'd still have to get the US on board, which seems unlikely. Or if you try blocking the harm that comes from the US, you get threatened with tariffs or abducted or something. Not to say it's not worth trying, but such a complex problem needs to be attacked from multiple directions.
To complete the comedy: What even is the difference between an app and a webpage to the average user (read: computer illiteral person)? It's the shortcut on the desktop/homescreen.
If only you could ship a desktop shortcut to your webpage, that would be a very inexpensive way to develop an app, and what probably most apps could have been.
If you have a webpage open in Safari on iOS, you can click the share button, "View More" and then "Add to Home Screen". It adds an icon to the home screen. Tapping the icon does not open another browser tab but rather spawns a standalone window, like a regular app.
This is how I distribute my "home-cooked" family expenses tool without publishing to App Store.
I find it amusing that, originally, Steve Jobs claimed that web apps were so good that you wouldn't need native apps and would just write web apps for the iPhone and now Apple's approval process is so painful that people prefer to write web apps for the iPhone.
I thought of that story, too, but I'm wondering to what extent it was his genuine belief, versus needing to say something because they didn't yet have a software distribution method he liked.
Reading this 9to5mac post from 2011, it seems at least part of the issue was he didn't think they had the moderation bandwidth (which of course presupposes that they had to have a centralised, monopolistic app distribution platform to begin with).
Tangentially, there's also this bit at the end:
I had a number of Symbian phones in the 2000s, and there definitely were apps clearly made by just regular people. Yes, they way you found out about them was from "best applications for your Nokia smartphone" type websites (of varying levels of jank), or enthusiast forums, so discovery was hard if you didn't know about those. But once you had a link to a
.sisor whatever, you just downloaded and installed the thing.I guess those phones were never popular in the US, where carriers did control everything.
This was also the reason I didn't think the iPhone would be successful. The US carrier environment made it really hard for any phone to show of its benefits and a phone designed for that environment would appear very bad in the rest of the world. I didn't take into account how much Jobs would be able to persuade AT&T. Even then, the iPhone was pretty bad. It didn't support 3G (my old Nokia did), it didn't sync with the Mac without a cloud thing (my old Nokia did), it couldn't make SIP calls over WiFi (my old Nokia did), it couldn't run third-party apps out of the box (my old Nokia did). It wasn't until Apple shipped the iPhone 3G and removed iSync from OS X that they reached parity.
I wouldn't mind the approval process itself that much* but I do mind having to buy a macOS machine and paying Apple ~€100/year just to publish something in App Store.
* Although I do think that sideloading should be available.
I must be doing something wrong: I added weather.gov to my iOS Home Screen using this approach, and it does indeed open a new tab in Mobile Safari.
Are you running an older version of iOS? Before version 26 it required a web app manifest to open a web page in stand-alone mode, but it was changed to use app mode by default for web pages opened via home screen icons.
I'm on iOS 26.
I deleted it from the home screen and added it back again -- now it opens in its own window!
Perhaps it was opening in a Mobile Safari tab because I added it to my home screen a long time ago?
My favourite bit about this is this, from the PR:
Quoting the AGPL: (but this clause is in the GPL too)
Not sure how it'd be possible to rectify those two things!
Other than that, I'd say it's not a bad idea; it's just not something you could use the GPL for.
I tried to clarify this a bit more in this comment, but the idea is that there's a license agreement for the source code (e.g. the AGPL), and an agreement for the platform that hosts it and the latter comes with the "you can't mirror the repository" agreement. This isn't really any different from say GitHub saying "If you post illegal content on GitHub you'll be banned": you can't access the platform any more, but you can still use the source code in accordance to its license.
Aha, OK. Making a clear distinction between "license to the codebase" vs "ongoing access to updated versions" is subtle but seems clever. Someone who paid for access and then stopped paying would be well within their rights to distribute the code they received, but not while they retained ongoing access to new versions, and rights covered by the GPL do not in any way imply ongoing access to updates.
Thanks for clarifying.
If you hold the copyright you can choose to distribute the work under multiple licenses, which may themselves be inconsistent.
You apply AGPL terms to the public version that is not current, you provide a commercial license for customers who want it, and do not offer them access to the source code under the AGPL.
TBH, I’m not sure that three months delay is really that load bearing. But some companies will pay to be able to link AGPL software to their closed source codebase, if it’s for something important. Sencha did this for ExtJS (regular GPL, since it was client side JS).
There's a few vendors out there that basically threaten their customers if they exercise their right under GPL, they will cancel all support contracts. Often, those are codebases that they don't hold all copyright for. So it's not even a new idea, it's generally considered legally sketchy.
The legal argument says that you are not imposing restrictions on the code that they receive, you are imposing restrictions on their ability to access future versions of the code. You may either exercise all of the rights under the AGPL, in which case you don't get the next version but you retain the ability to exercise all of the rights to this version, or you may exercise a subset of them and then get access to the next version.
Several lawyers have had strong opinions on this strategy. They did not agree.
The other issue is that licenses such as the AGPL pass on these rights to all downstream people. And you can't restrict what they do. So you're effectively saying 'don't distribute this'.
The problem is that it's missing why people want open-source languages. They have decades of experience being locked into vendor-specific toolchains. The thing that they want from open source is either a second source or a strong possibility of a second source, including doing in-house things that integrate the tooling. That often rules out GPL-family licenses and definitely rules out anything where the project is structured to ensure that outside contributors cannot become maintainers of a fork.
Do... people normally only hold a phone in their primary hand? I'm left-handed but hold my phone in either hand about equally at random, and kind of just figured everyone did that.
I'm left handed and nearly exclusively hold my phone in my right hand. The cause is simple: at first I held my phone in my right hand, and used my left hand to interact with it. As time went on, I used my right thumb to do more and more things, until it became the primary interaction point.
Similarly I use the mouse with my right hand because in the computer lab growing up the mice didn't have long enough cable to switch over and use my right hand.
left handed people tend to have a dose of ambidextery, as the world really wants us to be right-handed.
left-handed here, but I also do a lot of things with my right hand, like handwriting. It's also my dominant hand on the piano (although the way most pieces are written certainly contributed to that). and yeah, I use both hands on the phone as well
Right handed here but I use my phone 90% with my left hand, maybe that's why I was so confused.
A data point: I'm definitely faster at touchscreen typing in my dominant hand. I can use either (it's not as hard as handwriting), but for anything more than a glance at the screen or a few swipes, it is more comfortable with my dominant hand.
I at the very least start swapping hands when one of my wrists gets tired of holding the 2026 mega-brick form-factor smartphones. You would think it is more common to at least have tried using both hands even as a "righty".
I am right handed and almost exclusively hold my phone in my left hand, so my right hand is completely free to interact with it. I don't know if I just have abnormally short fingers (I don't think so? they look fine), but I find it really awkward to interact with my phone with the same hand that's holding it.
So, if I'm scrolling on my phone, it'll be phone in left hand, scrolling performed with an arbitrary finger of the right hand.
I'm ambidextrous with a slight bias towards fine motor control on the left and coarse motor control on the right. I tend to hold my phone in my left hand because I use my right hand for mice (experience, not innate bias - I can use either, but most computers I used as a child had the mouse pad on the right and moving it didn't make things better [or worse], so I didn't) and so pick up the desire to use the same hand as my pointing-device hand.
When doing anything more than looking at the screen yeah pretty much only ever the correct hand.
Right handed here, and I use both. I probably favour my right a bit more, but from some quick anecdotal testing I seem to type better with my left hand on my phone than my right (although for anything longer than a couple of sentences, I'll use both thumbs to type).
I use my phone with whichever hand is comfortable to reach for it, which is usually my nondominant left because I keep it in that pocket. It strikes me as absurd that someone's handedness might lead them to prefer a hand for one-handed phone use, because I have no preference at all unlike in most domains. But maybe that too is an accessibility blind spot.
Why stop at signedness? Integers should be bignums by default, for much the same reason.
For that matter why stop at integers? Math should be rational by default. This one is very slightly harder to justify because sometimes one really does want IEEE 754 floating point numbers for a calculation, but note the word ‘default.’
I know that we’re all used to machine ints and floats now, so they do not seem surprising, but I suspect that for a layman it would be less surprising for computers not to have problems with negative, large or rational numbers.
Users also express surprise at out-of-memory errors, and bignums can allocate all over the place.
These are engineering tradeoffs. There's no perfect & affordable solution here.
I really like the Smalltalk / Lisp choice that integers are things that are stored inline in the pointer but automatically promote to BigInt on overflow. On a 64-bit machine, that typically gives you a 61-bit signed integer as the default type, which is big enough for most things, but which gracefully fails over to a slower path that doesn't lose information on overflow.
That's not appropriate for systems programming, where you need to be able to do arithmetic that definitely won't allocate memory, but for application programming it's almost always the right choice.
It is elegant.
For application programming my integers often end up in Postgres which has sized types too, and some correspondence between valid application state and serializable/persistable state can be good.
Also - does this trick work properly with CHERI/CHERIoT?
I suppose you can do similar tricks with float NaN values for a generic 64-bit numeric type…
Yes, though you can actually do better on CHERI systems because you can use the tag bit as the discriminator. On CHERIoT, you can have a union of a 64-bit integer and a pointer taking up the same space as a pointer, so you can use the full range of the integer (unless you want to store more types inline, then you might choose to steal some bits for a discriminator).
This is also not powered by green energy. There are gas pipelines being built directly to data centers for on site generation. Wait times for turbines have gone up years.
We are setting our future on fire so that we can accelerate enshittification.
I am very glad I don't have children.
If they were, it would be an irrelevant distraction. Electricity is fungible. 1 MW of consumption means 1 MW of consumption. If your 1 MW is produced by green energy, that means 1 MW of green energy that isn't available for other uses. Unless it's powered by green energy from production projects built specifically to power that thing, then it's an accounting trick not actually a green shift. And, even then, the huge demand spike may be making green energy less affordable for other uses (up to a certain point, more demand means more economies of scale and pushes prices down. Beyond that, shortages in the supply chain mean that the price goes up).
I was depressed when I was at MS that there were people on the Sustainability Committee, who seemed to genuinely care about not making the planet uninhabitable, who would nevertheless justify running enormous machine-learning jobs because power to Azure could be met with green energy production.
I think this mindset is flawed. You can put yourself in any point in history and you will still find reasons to not have hope for the future. I mean I definitely won't argue the world is perfect, but it's a whole lot better than 100 years ago. or 200 years ago. or 300... Each generation fights its own fight, that's the way it goes.
To be fair, no generations other than those currently alive had to contend with accelerating anthropogenic climate change at this scale.
"The Dawn of Everything" by David Graeber and David Wengrow in part argues, I think quite effectively, that these kinds of statements are based on rather arbitrary criteria of "better" biased on the status quo. There is no linear progress of human cultures that can be assessed with a moral value system, the way we like to see it; it's more complicated.
No, but in the past, generations have had to deal with plagues that killed off 30% of the population (or 90% in the case of the New World contact), regular famines (less these days, which are now more a political problem than a natural problem) and as always, a high rate of infant mortality. It's always getting better (but not equally everywhere), but at the same time, the problems we do face change.
Which reduce the population, not the ability of the environment to support people.
I wonder how snmalloc compares. I might test it later this week when I have time.
I vaguely recall that I implemented the trim API in snmalloc, but apparently I never pushed it, and it was probably on my work machine so is gone. It's a bit tricky in snmalloc because the design has a couple of tiers:
There's a global range allocator, which will call
notify_not_usingin the PAL when a large chunk of memory is unused. On Linux this callsmadvisewithMADV_FREEif you have a recentish kernel orMADV_DONTNEEDon older ones. It took Linux a long time to getMADV_FREE, unfortunately (XNU has a nicer variant, I never got around to upstreaming the FreeBSD version that an intern implemented for me).But there's also a layer of caching. Each thread owns an allocator, which manages its own free lists (if you free from another thread, it's a remote free and is batched and sent back). A thread-local
malloc_trimimplementation would return free slabs to the range allocator, but ideally you wantmalloc_trimto operate globally and that would require some synchronisation that (for performance) is intentionally not there in snmalloc.I'm not quite sure what
MADV_FREEdoes to RSS accounting on Linux. The semantics are that reads will either return zero or the old contents: the VM subsystem can steal the page at any point and replace it with a CoW zero page. Writes will either do the copy and give you a new zeroed page, or will make the old page no-longer available to steal. I'd expect pages to still count to RSS until they're actually stolen, which means that you won't see RSS drop unless there's memory pressure.The way that
MADV_FREEis normally implemented is that you set a bit in the page metadata indicating that it's in theMADV_FREEstate and clear the dirty bit. At some point later, when you experience memory pressure, you look for pages that are in theMADV_FREEstate. If their dirty bit is clear, you first make the page read-only, then you check the dirty bit (in case it was concurrently modified), then you update the page to point to the canonical CoW zero page. You hold a lock while doing this that means any racing write will be serialised (when it enters the page-fault handler). This makes putting a page in theMADV_FREEstate very fast, but means you don't get precise RSS accounting when there are pages in that state. The XNU version provides an explicit operation to take pages out of theMADV_FREEstate. If the page hasn't been recycled, this is very cheap (just clear that bit from thevm_page), if it has then it's a new page allocation. This gives you precise RSS accounting, at a cost of a small amount of performance.Modern operating systems are optimised for the case where the available memory is large. Running out of memory is an infrequent operation that hits slow-path machinery. Until you hit that case, memory should be easy to use and quick to allocate.
TL;DR: Don't expect RSS to actually be meaningful with a modern allocator on Linux or FreeBSD. RSS is the amount of physical memory that your process can use cheaply. If other processes need more memory, there is some amount between 0 and 100% of a process' RSS that will be reclaimed without swapping.
I did have an implementation on Windows that used the low-memory notification to return pages when memory was low. Unfortunately, Windows doesn't trigger this until physical memory is exhausted. If commit is exhausted but there's a load of physical memory free, you don't get this notification and so it wasn't actually useful.
EDIT: For a while, we didn't use
MADV_FREEon Linux because using it came with a pretty noticeable performance impact. No idea why Linux is so much worse than FreeBSD or XNU here.On Linux, Go's allocator prefers MADV_DONTNEED. It has worse performance characteristics (it's eager instead of lazy, in my measurements MADV_FREE, at least in modern Linux versions, was quite a bit faster), but it actually updates RSS numbers immediately. You can find policies that work with that eagerness to keep the overhead low at the cost of less frequent (but still acceptable, if you consider hugepages as well) return, if you're doing it as you go.
On the one hand you're right not to trust RSS. On the other hand, everyone's monitoring tools trust RSS.
Go has been through a whole saga on this, and this is where things have settled for a while now. It may not be the right trade-off for every project, but made sense there.
It’s on a slow path, so we could probably make it a configuration knob in the Linux PAL (it’s actually templated already, just not exposed for user tweaking easily). Set this way you want it to to work well, set it the other way if you want differently misleading RSS numbers that look better.
This why I wish everyone would implement the XNU APIs.
I am generally of the opinion that languages shouldn't do automatic type promotion and should default to signed integers. Multiplication should always have a result type that is double the width of the operands and should have explicit non-widening versions.
The thing I would like to see more of is Ada-style (Pascal-style?) explicit ranges. Unsigned integers are a special case of this that happens to be easy to represent. But if I know that I'm storing integers in the range [0,100], then I should be able to say that, not just say 'well, it fits in an 8-bit integer and I don't want negative values so I'll pick u8 as the type'. And I want to define wrapping or saturating behaviour, or operations that return larger ranges or require me to put the thing back in line. And the compiler should pick the narrowest machine type that can store the range I want.
Can you explain why you wouldn't want automatic widening in the following case?
I think x should be widened to u64 here without having to cast it.
Because consistency is really important for people being able to keep rules in their head and if I widen there then I have corner cases. If
xisi8, I either don't widen (unless I want to introduce a complex set of integer promotion rules that lead to bugs), so now I have some heterogeneous types that support implicit widening but others that don't. Maybe it's okay to implicitly widen but not change sign, but generally my experience is that this is code where I really want the reviewer to think about the behaviour. Why am I adding au8to au64here? Why isxau8, if it's being used in arithmetic with au64?In this small contrived example, it's obviously simpler than writing
zero_extend<u64>(x) + y, but when I come to review it I can see that this is correct and I can ask 'why doesxneed extending? Is storing it as au8actually saving anything useful?', whereas with the code as you've written it there's some unstated design assumption that may or may not be sensible that isn't exposed.If I had my way, the promotion rules would be signed can be widened into a larger signed, and an unsigned can be widened into a larger unsigned, but you should not be able to automagically widen an unsigned into a wider signed, nor a signed into a wider unsigned. That should require explicit coding.
Shortening is an issue (going from u64 to u32 or i62 to i32) and should also probably require explit code.
I agree with @spc476 here. I think this is a pragmatic exception to the no-integer-promotion rule: signed widens into larger signed, unsigned widens into larger unsigned. I think it's simple enough that it's easy to keep in one's head. The number on the right side of the type can get bigger, but not smaller. I do agree with @david_chisnall that it is good to force unstated design assumptions to be stated. It may point out flaws in the larger system, which is extremely valuable. But there must be a middle ground, as after a certain point it can be boilerplate, which increases maintenance cost and cognitive load on readers of the code. Sometimes I just have been given a u8, and a u64, and I want to add them.
I think it comes down to the type of language one is designing. For a systems language like Rust, I think no integer promotion is reasonable. For a scripting language, it is less reasonable. Thoughts?
For a scripting language or, indeed, any application-programming language, I think fixed-width integer types should be for very specialised cases. The default should be a Lisp/Smalltalk-style integer, which is stored in a word if it fits and transparently promoted to a heap-allocated (immutable after creation) big integer object on overflow. The original Smalltalk on the Alto had signed 15-bit SmallInt integers that were stored in a word and anything that didn't fit in this range was promoted to a BigInt. Most 32-bit implementations do 31-bit SmallInts. 64-bit ones often do 61-bit SmallInts and also have inline-in-a-pointer small strings and floats (one Smalltalk vendor noticed that most double values repeat the last bits of the mantissa in one of two ways so provided two types that let you just fill in those bits with a tiny bit of bit manipulation and fell back to heap-allocated values for other floats).
Generally, this impacts performance noticeably only in cases where you could otherwise vectorise things and it's fine to provide specialised limited integer types for things like JavaScript's TypedArray family that let you store big blocks of data that you want to do arithmetic over. If you're doing, say, image convolution, then you have specific overflow behaviour in mind (typically saturating for that one). For the common case, it eliminates a bunch of failure cases and reduces cognitive load (I just know I want an integer, I don't care what kind of integer, representing it efficiently is the compiler's problem not mine).
For a systems language, arithmetic sometimes triggering memory allocation is completely unacceptable, so you do want fixed-sized integers there.
Now here's a question: what if it's a scripting language for embedded platforms? I'm having this issue now and not sure if the Lisp-style int cost (implementation complexity, memory allocation) is outweighed by the benefits (cognitive load, fewer edge cases).
The issue with memory allocation isn't "do we have enough memory," it's "we can't predict our memory needs well". But this could be solved by preallocating enough space for this at startup.
Scripting for embedded is tricky because embedded really wants deterministic allocation so that you know when it’s going to fit. I’ve recently been using Microvium, which is a tiny JavaScript VM that is quite similar to the Smalltalk 80 VM, but it uses a single fixed-sized number type.
The normal thing would be to use double, but a lot of embedded devices don’t have FPUs, so a single integer type and some defined overflow behaviour is probably better.
Object pointers in Microvium are 16 bits (shifted offsets into the heap region, which may be a linked list of allocations: it turns out memory is tight but CPUs are unreasonably fast relative to memory size on most embedded systems), so you probably could do the same thing and promote anything that isn’t a 15-bit signed value. Heap allocation is cheap (bump the pointer) on such a small system and big units are leaf objects so don’t add much GC cost. I’d possibly be inclined to not promote above 64 bits, since most values you need in embedded systems will fit in 64 bits.
Yeah, tho a modern programming language should do it better.
The problem with ranges of that era is they were fixed by the variable declaration. It was easy for intermediate results to bust out of the declared range, and it was inconvenient to relax the constraints within a procedure even if the final result was known a priori to be in range, or if the programmer wanted their own range error handling.
Nowadays it would be better to infer the ranges of intermediate values through arithmetic ops with some abstract interpretation, and allow normal range checks in if statements (etc) to narrow the types. Something like what ATS or refinement or liquid types do, tho I suspect there is a way to provide those kinds of features in a manner that’s more palatable to programmers who aren’t formal methods geeks. TypeScript’s flow-aware type narrowing is a step in the right direction.
What it should look like to the programmer is that arithmetic works in the same mathematically correct manner as bignums, but because the compiler knows the bounded range of all values, it can compile efficiently using fixed width numbers. And comparisons between numeric values should always return mathematically correct results for any pair of types: it isn’t even that hard to correctly compare (say) an f64 and an i64; if the programmer discovers that a correct comparison is too slow they can either use an explicit conversion to throw away some bits, or add a range check earlier to ensure (say) the i64 is within the 53 bit floating point integer range.
And range types eliminate the need for any special case bodges for integer literals: the type of a literal is simply the range covering exactly that value, and there’s no need to work out a more specific type later depending on its context.
Do you have a paper on this?
Sadly not, I’ve been looking at the literature for the things I mentioned (ATS, refinement types, liquid types) but as I complained, they aren’t quite the shape I want. (Maybe I should wonder over to the university computer lab and chat with the PL researchers…)
Also worth noting sign extension as probably the strongest case against both automatic widening and promotion from unsigned to signed and vice versa.
It's extremely easy to introduce subtle bugs if you don't pay attention to the fact that e.g. 0x70 widens to 0x7770 as a signed byte, but 0x0070 as an unsigned one.
Um ... wouldn't 0x70 widen as 0x0070 regardless? 0x70 doesn't have the sign bit set. It's 0x80 that would sign extend into 0xFF80. From the number you used, I think you mixed octal with hexadecimal. It would be 070 that extends into 07770. I hate that C uses a leading '0' to mean octal.
C29 will let you use an
0oprefix to indicate octal. https://en.wikipedia.org/wiki/C29_(C_standard_revision)#ConstantsThat is very correct, I was getting my wires crossed when thinking up an example.
The fact that your example is wrong rather reinforces you point that this is confusing.
Does that mean the compiler should be smart enough to know the bounds of the value and error out on paths that are undefined/out of bounds?
Explicit ranges are exactly what I'd prefer too. However, I'm not sure what the correct run-time behavior on out-of-range should be, panic?
I'd suggest it should produce the same compile-time error as:
because this the same (potential) out-of-range assignment problem if you do abstract interpretation and track how the ranges flow through the code.
I think hwj is more interested in cases that aren't amenable to compile-time analysis, For example:
That problem does not exist under static bignum rules: All you need is correct type inference: The resulting type of each mathematical operation is exactly wide enough to represent all output values.
For addition:
So that's an invalid program that shall not compile. Slap on the fingers! We get forced to either redeclare i to accept the widening…
… or do a narrowing conversion. Note that we don't need a special narrowing conversion: Again, the result of each mathematical operation is exactly wide enough to represent all output values:
That's what we have to do if we are summing unbounded input. Admittedly, the overflow detection is essentially manual:
Except that should be solvable with a macro and a Result type. This way, all unavoidable overflow is explicit and must be handled. And we avoid the avoidable. We get a language that is safe yet panicfree.
Hrm, that's true. Does make me wonder how typing would work at some points, though. For instance, how would you type a non-wrapping/non-saturating
sum()?Reminds me of interval arithmetic, if anything, though I'm not familiar enough with the field to say to what extent the benefits/drawbacks transfer, if they do at all.
That's where I want to see explicit type-level choices for this. The valid options are:
iis 0.iis 100.i++isn't defined buti + 1evaluates to a union type of eitherint[0, 100]orOverflowError(which may also encapsulate the overflow in a type that is guaranteed to support be able to hold the result, such as aBigInt) and each addition must check this condition (or explicitly discard it).The last one is useful in some niche cases, but the choice of which to use should be part of the type.
From the other side of this recently:
LinkedIn is a complete waste of time. It's full of totally unqualified people. You'll get 10x the number of CVs from LinkedIn than from any other source, but you will get maybe half as many that meet your shortlist. Oh, and, if you post a job on LinkedIn, they will add their own submission system, which doesn't ask for the information that the job ad asked for. They also do some 'AI' prefiltering, which is worse than keyword matching.
LinkedIn aside, there are a lot of competent people on the job market at the moment, with the exception of a handful of areas where 'AI' startups are hiring in enormous quantities with enormous salaries. Big tech companies shedding 10-20% of their workforce over a few years means that there are a lot of good people looking for jobs. That means companies can be a lot more selective than normal (from this post: if they want an Elixir developer who is also proficient in TypeScript then they probably have several in their hiring pipeline).
Oh, and if you don't require people to use AI, you get a much better talent pool to select from.
This is less true for companies requiring people to be in the office, unless they're close to one of the big layoff areas.
Interesting link to explain what can be changed or not regarding ABI focus on C++
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B
Those look like pretty good recommendations. That said, I disagree on this one:
That's almost certainly a terrible idea. Modern compilers have a warning if you don't include all enumeration cases in a
switchstatement. This warning is disabled if you add adefault:case, so a lot of codebases omit thedefault:to make sure that the compiler catches the cases. In these cases, the switch statement will be skipped entirely in code if you actually use the new enum values.Here’s some friendly advice. In the working world, what marks you as a professional is how you handle situations that are broken. Anyone can remain in control of themselves when things go as expected. But pros stay cool regardless.
Remember: When things are broken, that’s when you get to decide whether you want to be a professional. It’s an opportunity.
Please understand that being a professional doesn’t mean you have to eat crap. It means that if you’re served a plate of crap, you know how to set it aside without drama.
If you set it aside without drama, then there is high probability that they will serve the same shit, or even more of it, to the next person. To the point where there is just shit.
If you force them to eat it themselves, then maybe there will be some afterthought.
There are ways of telling someone that their behaviour is unacceptable that will make them reconsider it. There are other ways of telling someone that their behaviour is unacceptable that will make them double down on it and disregard your opinion. Part of professionalism is being able to communicate dissatisfaction in the former way. No one can do it all of the time (especially not if they're subject to the same behaviour repeatedly).
And of course, what "the former way" is exactly highly depends on who you’re talking to. And that’s if they can be made to reconsider at all. How many of us have been taught how to manage their managers like that?
No, you're missing something important: In a professional context, drama only makes your message easier to dismiss. Think about the people responsible for a broken hiring process. They don't want to hear that they screwed up. That's a message they will try to set aside. So, if you deliver that message within a bright, blinding opportunity to classify your message as a childish outburst that should be dismissed, rather than an unignorable reality check that must be taken seriously, they'll take the opportunity you have given them.
Which is exactly why it is a waste of time and energy to even try to tell them. Real change requires real consequences for those people. Often, the best way to deliver such consequences when you have no actual power over them, is to tell everyone else.
Sure, but when you tell everyone else, why wouldn't you rather do it like a professional would? How does it serve the cause to tell everyone in a rant that comes off as childish?
As I said in a sibling comment, that rant didn’t sound childish to me. And to be honest I don’t like the tone policing: most of the time, the most effective tone is not the most polite. It’s something more personal, more direct. Not some corporate friendly writing that sounds like it’s been written by an LLM.
Nobody said it was. What I said was—let me try to say it in yet another way—that your words are more likely to be taken seriously if you come off as a level-headed professional and less likely to be taken seriously if you come off as a disgruntled candidate ranting with raw frustration. Do you find this claim controversial?
TBH I do not care whether they will change their approach to that. I am describing the pathology of the process. It is up to them whether they will do anything about it.
Again - they did not pay me to review their process. I have no regard about their feelings if they discarded my messages, that it is not what I agreed to. They find it childish - I cannot do anything about it, nor I really care. My own mental health is much more important than what some corporate "thinks" of me, and seeing their behaviour - they didn't value my expertise.
Please understand that I'm trying to help you. I assume you want to land a good job, yes? I assume you want to be taken seriously, yes?
Look, you're obviously smart. If you want to rationalize your behavior, you clearly can come up with all sorts of justifications, but I'd ask you to consider whether there's some truth in what I'm trying to tell you.
I'm going to try one more time.
Doesn't matter. What does matter is how your behavior—during the interview, when you wrote about it on your blog, and when you doubled down on it here—shapes the world's perception of you and how that perception helps or hinders your pursuit of your goals and dreams.
I think you want to be perceived as a serious person, a professional that any top company would be delighted to add to their team. If so, the questions you ought to consider are: Does your behavior, your very visible behavior, argue that you are a professional and that hiring you would be a great idea? Or does it argue that you have questionable judgement and that even interviewing you is a risk that could blow up on them?
Your duty to be a professional is not conditioned on their behavior. It's a promise you make to yourself and to society. Again: It's not conditional on their behavior. If they disrespect you, that's not license to disrepect them. You always treat other people with respect because that's what a professional does.
Do you seriously believe that your behavior has nothing to do with how others perceive your behavior? It's not just that the people involved in this broken hiring process find it childish. I'd estimate that approximately 100% of people in a position to hire you would find it childish. Do you care about landing a good job? Then you ought to care about how your behavior reflects upon you.
Of course your mental health is important! But there are other ways of opting out of a broken hiring process than behaving in a way that makes it harder for other companies to hire you. Being a professional doesn't mean you have to be a pushover. It just means that when you opt out, you do it like a professional. And doing it like a professional means firmly but politely withdrawing your candidacy, not writing a rant about it on your blog, and not doubling down on your rant when people try to helpfully point out how your behavior is likely to reflect upon you and affect your career prospects.
We aren't lawyers. Our professionalism is rooted in the quality of our advice, not our workplace conduct or adherence to some bogus creed. The reason to keep a cool head is to avoid offending management. The reason to keep language polite and neutral is to avoid hostile-workplace lawsuits. We aren't suits or squares.
(I'm going to reply in earnest and assume you aren't trolling.)
This claim defies what the public and members of most computing-related professional societies expect of professionals. In short, your professionalism should carry through to everything you do: not only the quality of your advice but also your conduct. Consider, for examples, the IEEE Code of Ethics, which states that, "We ... do hereby commit ourselves to the highest ethical and professional conduct..." and the ACM Code of Ethics, which requires members to "Maintain high standards of professional competence, conduct, and ethical practice." (Emphasis mine)
I'd say that the reason to keep a cool head and to keep language polite and neutral is that that is what is expected by the public of professionals. The reason it is expected is that to be hot-headed, impolite, or biased in professional communications increases the chances for mistakes and misunderstandings, and in engineering contexts mistakes and misunderstandings can have serious consequences.
Was there some reason this was posted now?
someone thought it interesting? not every post requires an exogenous motivation!
It’s not a very detailed explanation of the two ideas, so I assumed this particular explanation was chosen for some reason.
What’s a better one?
I’m not sure, but I’d expect some examples, some of the corner cases, and so on. The one-liner of ‘ABI changes mean you must recompile a dependency for it to keep working, API changes mean you must modify the source for it to keep working’ gives you about as much information as this.
It was actually interesting to me
This is interesting to me as well, understanding what an API is very well but barely having had the need to understand what an ABI is, or the problems with an unstable or incompatible ABIs. It's been one of those background questions I had simply left wanting for the time an explanation shows itself to me, like this post here :)
Bryan Cantrill was right again
I'm curious about this. What was he right about? I don't have any context.
I think it’s this: https://news.ycombinator.com/item?id=13739527
Gauche to confess, but I honestly had the same first thought.
Would you be so kind and provide some context? :)
Bryan has mentioned that he dislikes epoll. From his prospective it’s an api that’s hard to hold and can cause heavy cognitive load on the consumer. It’s a “good enough” api when compared to kqueue
There’s some podcasts with the bsd cast where he mentions it but I can’t find the episode right now.
Another concern was along the lines of the parents getting stale messages from a child that dosent exist (verify this because it’s off the top of the dome)
Edit I believe it’s somewhere in this podcast:
https://youtu.be/l6XQUciI-Sc
I don't think that's relevant here. A similar bug would be fairly easy to introduce with
kqueue. The back end of both look quite similar, it's just the user-facing interface toepollthat is awful.I really wish the Capsicum for Linux effort hadn't been killed by NIH. It's a far better model for sandboxing desktop applications (launcher grants them a set of initial capabilities [file descriptors] based on their metadata and they can't access anything else, powerboxes provide capabilities for opening and saving other things) than the pile of things that are used in Linux to try to achieve the same thing.
The whole Linux container model is a kinda scuffed patchwork of concepts that align mostly with running something akin to kubernetes services where services are orchestrated by some god-process, but don't really fit in a desktop environment where you'd want the ability to enter a lower privilege cgroup/namespace from userspace without going through the sort of root daemon or setuid rigmarole that inevitably invites privilege escalation risk.
It's also the wrong abstraction. The container isolation model is similar to jails in FreeBSD and Zones in Solaris: they're isolated worlds that look like VMs, you get something that's close to a separate computer. The thing I repeat all the time:
Isolation is easy, sharing is hard
The hard bit for application sandboxing is that it isn't an isolated environment. A sandboxed app that I run wants to have access to a document that I ask it to open, but only after it pops up a dialog box and I select the file, and only until the program quits. I want it to read from the clipboard, but only after I either use a standard keyboard shortcut (which the windowing system can intercept and grant access to the current clipboard contents before forwarding the event).
These very dynamic things are the kinds of things Capsicum was intended to support. You can start with access to a socket that talks to the windowing system, maybe access to a GPU device context, access to a temporary directory that is specific to this run and will be cleaned up at the end, read-execute access to shared libraries, and so on.
I heard about landlock semi-recently, it seems promising on that front, afaict.
Landlock remains path based, which leads to all sorts of confused-deputy and aliasing problems.
In theory this is how the major Linux desktop sandbox tools (Flatpak etc) are supposed to work, with
SCM_RIGHTS+ Wayland + D-Bus acting as the primitives. You can sort of see the outline of a secure desktop if you squint.But the actual implementation on all sides is some combination of overly permissive, inflexible, and half-broken. Nobody seems to care about securing it end-to-end in the same way that people care about securing server workloads, which is why gVisor and Firecracker work so well but Flatpak can't even run a basic Gtk+ application without breaking the fonts, and every Wayland compositor has to re-implement half of the trusted desktop base.
It's even more embarrassing given that Android has done a fairly competent job of being a Linux distribution hardened enough to run untrusted code in, while iOS and macOS have shown that user-facing application sandboxing can be highly ergonomic. Just do what they do! Why the hell is anything in the window manager reading
/proc/{pid}/cmdline??Kind of. Android apps have a far simpler model for sharing (and some big holes when you try to make it look more like desktop interaction models).
Capsicum was designed, with input from Apple folks, specifically to support the sandboxing models that OS X shipped. They didn't switch to it because they'd already built something that did 90% of what they wanted on top of the TrustedBSD MAC layer and rewriting the whole thing with Capsicum was not desirable by that point.
..are we talking about the platforms that don't even allow to access filesystem ? For actual serious apps it's a constant pain in the ass for the end users and usually the basic answer to "the app i downloaded cannot find the files I need to do my work but I see them in my Documents" is "use another OS". Yay for highly ergonomic.
I use all three platforms (Ubuntu workstation, macOS laptop, Android mobile) and the macOS sandboxed apps are fully capable of accessing files. They use a mechanism similar to the XDG "portals" from Flatpak.
The major behavioral difference is that they need to be granted permission to access those files, so when I open up a document editor I have some assurance that it's not going to exfiltrate my SSH keys.
I feel like these are measuring very different things? The scope of firecracker in particular is far narrower, given that it's "just" a micro VM implementation—not to discount the effort it takes for that, but Flatpak is trying to wrangle an existing and very complex ecosystem, whereas firecracker is doing a very good at mixing together two singular existing things (containers and VMs) and building on top of that existing infra. gVisor is certainly much much more involved, being basically a userspace kernel, but that's more practical when it's backed by Google money.
...both of which are also backed by big company money and have the privilege of being able to tell the developers within "lol, cope" when making the necessary breaking changes. Linux userspace does not have that luxury.
Both of these mentioned have more tractible sandboxing because it's intertwined with the application platform. Linux userspace also does not have that luxury.
Flatpak has a much narrower scope than either Firecracker or gVisor, in that it only needs to provide a capability-passing mechanism on top of existing well-defined primitives.
Flatpak should not try to wrangle an existing complex ecosystem, because that's what makes it insecure. It ought to define a secure API and then require applications conform to that API to be used in its sandbox.
Flatpak is also backed by big company money (IBM).
Given that a breaking change vs POSIX is required to get capability-based sandboxing, Flatpak has the option of telling developers "if you want to be run in Flatpak then you need to use these new APIs for sandboxing". Right now it's telling users "lol, cope" when they want to sandbox applications running on their machine, which is how you end up with articles like this link.
You don't have to handle arbitrary Linux binaries. The set of APIs needed of a typical desktop application is much smaller than that of the entire Linux kernel, and (just like in macOS) users have the option of installing an application outside the sandbox if they really want to.
At present Flatpak's approach is to pretend to sandbox applications while allowing them to retain nearly complete access to the host system, and the user doesn't have the option to restrict applications other than rebuilding them. That defeats the entire purpose of a sandboxed application distribution platform (where the user should not need to trust the application to be well-behaved).
I'm admittedly using "Flatpak" quite loosely to include stuff like the XDG portals in here, but yes as mentioned below, a brand-new shiny capability-passing mechanism would simply have been used by nothing. The difficulty in Flatpak + portals is making something that's usable without as much manual changes to critical areas (e.g. the file chooser portal exposes files over FUSE, because then the application can treat them afterwards like usual), and trying to match the byzantine complexity of host-side configuration when required (for stuff like fonts and graphics drivers).
Ah yes the entire active maintainer team consisting of checks notes a single person.
If this happened, Flatpak simply would have never reached any adoption. Getting anything major done in the Linux desktop world is like pulling teeth, and Flatpak's wider use is a relatively recent phenomenon. Lots of projects did not even have portal support for a very long time, and many of those additions were external volunteer efforts.
This link is entirely a KDE-side bug, by this logic the multiple fatal bugs in Pixel hardware decoder drivers are a failure of SELinux. No sandbox is going to save you from exploits at a higher level, and Flatpak already provides ways to tie an arbitrary PID to the enclosing sandbox / app.
I genuinely don't understand what "nearly complete access" is referring to? All static permissions can be changed with
flatpak overrideor flatseal. Dynamic permissions are only granted as requested and gated by portals (and can be manually overridden). If you want VM-level isolation...well macOS and Android don't go that far either, do they?If IBM wants to hire more maintainers for Flatpak then that's well within their ability. Google spends more on gVisor than IBM spends on Flatpak because Google values having a secure sandbox for executing untrusted code, and IBM doesn't seem to.
I think this is the main point of disagreement. A capability-passing mechanism would have been useful, and may have been adopted to enable distributing Linux desktop applications with the same simplicity as Android or iOS applications. Eventually there would have been a split where easily sandboxed applications get distributed with a Flatpak-like mechanism and applications that don't fit the sandbox model still get distributed with Apt or whatever.
Instead we end up with Apt providing unsandboxed installation, and Flatpak providing insecure sandboxing, so there's no reason to use Flatpak.
Building an application distribution that doesn't have effective sandboxing doesn't provide much value over existing solutions (Apt, Docker / Podman, tarballs) so there's no incentive to adopt it.
The last time I tried to use a Flatpak-distributed application (Gimp) it installed with full filesystem permissions. Looking at https://flathub.org/en/apps/org.gimp.GIMP there's a list of permissions it wants, which includes both "Full file system read/write access" and "Network access".
That level of capability either shouldn't exist (as in macOS / iOS) or it should require explicit user opt-in, instead of requiring the insecure application to be installed first and then manually fiddled with via obscure command-line tooling. If I'm going to open up the command line anyway then I might as well just run it in a proper sandbox with waypipe.
I'm not sure if Capsicum is good though. I looked into it a while ago as part of figuring out how to get some form of first-class sandboxing in Inko (using OS primitives, so Capsicum on FreeBSD, Landlock on Linux, etc). From the top of my head the big issue with Capsicum is that you need to create all the necessary file descriptors ahead of time, but you can't always do that. FreeBSD's approach to making this more manageable is libcasper, but this requires you to explicitly write your code with that in mind (i.e. instead of calling
foo()you'd have to call thecasper_foo()equivalent, if one exists to begin with).Perhaps unsurprisingly, Capsicum doesn't see much use from what I know. For example, from what I remember both Firefox and Chromium don't do sandboxing on FreeBSD because of how frustrating/limiting the Capsicum API is. On OpenBSD I believe at least Firefox uses both pledge and unveal, not sure about Chromium.
The better API to copy is probably pledge and unveil from OpenBSD, precisely because they are simple enough to use so people actually want to use them while still being good enough for most cases. Unfortunately Linux seems stuck in this repetitive pattern of introducing very low-level and verbose and clunky to use APIs instead, with even Landlock being kind of a pain to work with.
UNIX domain sockets can carry new file descriptors, so it’s easy to have a more privileged process pass file descriptors. We had a demo almost 15 years ago of Qt patched to make open and save dialogs run in a separate process and return new file descriptors. Unfortunately, because the internal APIs all work with strings, this was quite hacky to make non-invasive (the strings carried the FD and propagated it during path manipulations. A sandboxing-friendly API would have the file dialogs return file handles).
Google rejected the Capsicum patches to Chromium for the same reason that they rejected all of the other FreeBSD patches: they don’t take patches to support targets Google doesn’t ship Chrome for. The Chromium team were the ones pushing for Capsicum for Lin though, because the sandboxing layer was significantly less code with Capsicum than with anything else.
The thing I would really like is bidirectional sync of PRs and issues with GitHub. The most painful thing about migrating is that it’s a flag day. Before the migration, you’re telling everyone to use GitHub. After migration you’re telling everyone to use the new thing. It’s like moving house: you always want a mail redirection for a few months so people who don’t know you’ve moved can still reach you. I would love to phase it as:
Without that gentle flow, there’s an abrupt transition that makes it painful.
Once you have migrated, the main thing I want is something that can import GitHub Projects for project management.
Bidirectional sync of PRs is mostly an anchoring problem, which is why nobody has shipped it well. Issues mirror fine because they're text with stable ids. Review comments are anchored to file + line + commit, and the moment someone force-pushes or the two forges compute the diff differently, every anchor drifts. GitHub's API makes it worse by exposing comment positions relative to the diff hunk rather than the file. Any forge that wants the gentle migration path you're describing probably has to store review comments against something more stable than line numbers, then project them onto whatever diff each side renders.
Cool project! If my team were to switch we'd need:
EDIT: One thing that would really help is an "Import from GitHub" button to smooth over the transition. Though it seems technically pretty hard to do it for code, PRs, issues, actions, etc.
GitHub's issue tracker is useful for public repos. But for private repos, most of the people use separate issue trackers like Jira, Linear etc..
Do you guys use github issues for private repos?
We use GitHub issues and Projects for private repos. We’re starting to use Linear because GitHub doesn’t make it easy to track issues that span multiple repositories that are public and private and get the planning views, but if a F/OSS GitHub alternative eliminated the need for Linear then that would make me very happy, especially if they offered a hosted option that I could just throw money at. Oh, but not if it’s one of these bullshit ‘open source, but the features that are essential to corporate use are proprietary’ things: I want a F/OSS thing so that there’s an easy second source if you go evil, if the features I need are proprietary then your going evil is a migration anyway and you’re just another SaaS provider that looks like it’s planning a rug pull.
JIRA should be used only between consenting adults, in private.
For cultural reasons I haven't seen it used in anger but I would be shocked if GitLab's issue tracker doesn't support that since they have first-class support for hierarchy:
https://docs.gitlab.com/user/project/import/github/#imported-data and because GitLab is MIT licensed I bet with enough time I could give you a link to the source code
That "actions" one has some nuance since of course the .yml come over for free, and would need analysis to convert to your new CI setup's mental model, but I actually don't see the CI secrets mentioned in that imported-data list. However, that's a gap in the automation and not "technically pretty hard"
I find the timing of these frustrating because they always come just as we complete a hiring cycle. We’ll be hiring more people in a few months and I fully expect that will also not line up with one of these posts.
You don‘t need to wait for these posts. You can "always" submit a job posting by using the corresponding tag.
Fine that it's possible, why does no one do it (looking back at history of the tag, last posting is over a year ago)?
Rules against self-promotion? Cultural/"feels wrong"?
Be the change you want to see in the world. I don‘t know how it will be received / moderated, but it is worth a try and probably without consequence if it goes wrong.
Why are all these solutions always starting with the stance that we all have to walk around with our IDs everywhere?
You could enforce adult websites to publish
X-Parental-Guidance:headers, and then have browsers / OSes respect it.Same effect, without putting the whole society under a privacy-leaking blanket.
But in this case, the government will have to approve the OSes and browsers that are legal, right? Because if I can just download an other browser on my computer and visit any site, it doesn't help much. I find the much more dangerous.
It's reasonable to expect a social norm that parents should not give their children administrative permission over their devices in order to install another browser. On mobile devices, which are overwhelmingly the most popular platform for youngsters by my understanding, that's probably actually good enough. On desktop, portable browsers easily get around this and we can expect kids to start learning what those even are quickly enough, but they come with their own inconveniences and that kind of intentional rulebreaking behavior is a perfectly normal part of growing up that we shouldn't be expecting to defeat through technical means. Just make it a crime to market a browser for this purpose and you defeat the economic incentives that would otherwise lead corporations to drive kids toward that behavior for reasons other than natural curiosity or rebelliousness.
On Linux, you can prevent portable apps by mounting /home and e.g. /tmp noexec. On Windows, group policy, I believe.
No, not at all, any more than a DVD player must be government authorised and will refuse to play DVDs with a certain rating without a government-issued token.
We put age recommendations on DVDs (and VHS tapes before that) so that parents have the ability to make informed choices about what their children watch.
If web sites that provide adult content are required to provide headers that specify the kind of content, browsers are entirely free to ignore them, but parents are also able to set up their children’s systems to use only browsers that reject pages with certain things in the headers.
If Facebook has to send
X-Parental-Guidance: AddictiveAlgorithm FarRightRadicalisation, it’s up to parents to decide whether to allow their children to install arbitrary software on their device and, if not, to define whether this is something that their browser must respect.There's a lot of things the government can do. They can sponsor and mandate proper protection on children's devices. Create a free parental control software. Create awareness programs so that it becomes the default among children. Ban devices in schools. Fine parents if children are caught with unblocked devices.
Notice how none of this takes the adult's freedoms away.
Anyways, I'm pretty sure with the current trend and modes of thinking, we will end up with both the government-approved devices, and the digital passports that will be required for everything, from filling taxes to buying toilet paper.
Well, fining parents if children are caught with unblocked devices does take away a parent's freedom to trust their child. Broadly speaking, though, yeah - trying to centralize identity management like this is so completely unnecessary to achieve the stated policy goal of empowering parents to protect their children that that can't be the real motivation.
EDIT: Realizing that may have come off as more of a vague accusation than I intended, I'll be clear - I think the real motivation is to implement the control over what all children can view that the concerned parents want exerted on what their own children can view. I don't think most reasonable people supporting this sort of thing actually want the surveillance state it creates, they're just willing to accept that as a cost of protecting their children, though I think it will fail to do that and still create the surveillance state.
I have yet to see a solution that either isn't anonymous or is vulnerable to one bloke helping hundreds of kids be verified as adults.
And by anonymous I of course mean that even if the government and age-checker collude, they can't find out who is behind which user/session.
This is anonymous, even if the government and the age-checker collude, there is no way to correlate the identity and the session. It's how a zero-knowledge proof like zkSNARK works.
Now, if you mean the government is giving a backdoored wallet that does not do what it says it does, yes, it can. But you don't have to use the govt-provided wallet either, they have published the source code on GitHub.
So it fulfills requirement A, but does it stop people from letting a bunch of children use their ID to verify themselves as adults?
As we've discussed in many other threads, this is probably absolutely not the case
Do you have a citation for this claim, because absolutely nothing that I’ve read about this algorithm class suggests that it is secure in the presence of collusion and communication via out-of-band channels. In particular, each token that the age checker generates is unique and it’s trivial for them to share a mapping between that token and identity with a third party.
In fact, I don’t believe it is possible to design a ZK scheme that has the desired property. Either each attestation is unique (or is a member of a small set), in which case deanonymisation in the presence of collusion is trivial, or attestations are not unique, in which case they are trivially forgeable.
The wallet can create a new zkSnark proof every time, based on the attestation it already holds.
I see, so that includes a random factor that means that you can't tie new proof to the original attestation, but you can still check the property. But if the attestation leaks (e.g. security vulnerabilities in the wallet), you can regenerate every proof that the wallet has generated?
That's somewhat less bad, though I still strongly disapprove of moving parental decisions to someone else's control. We set the correct precedents when home movie rental came along, we don't need to do the opposite now.
You don't need snarks and all that, I think you just need a bunch of one time use blind signatures.
And afaik those should provide complete unlinkability, since the unlinking step happens in the client wallet.
Just a thought: What if we made online platforms liable for harm to the people? What if they were responsible for all the hate, misogyny, and radicalization?
If the platforms stopped hosting all of the content, if they stopped optimizing for engagement/rate bait to maximize clicks and ad engagement - maybe the internet wouldn’t be so fucking harmful for people out there (not just kids. Everyone.)
If we made online platforms liable for users' harms, all small, non-profit social spaces, including this one, would disappear in a year or two. The US's Section 230 protects independent communities because it "creat[es] broad immunity that allows the early dismissal of many legal claims" rather than being a defense subject to ruinous, draining litigation. If every coffeshop was liable for harm done on its premises, dumped lovers would bankrupt everything smaller than Starbucks. You would see less harm in the same way that paving over a playlot results in fewer injured children.
I think there is a difference between:
I am consistently disappointed to hear/read people concluding that "f(x)" is an inconceivable solution to a problem because when x is very large bad things happen. Just put boundaries on x then and see things get better. Obviously this is a simple metaphor, but I think it gets the point across.
I think more broadly, people should start accepting that imperfect solutions are valid when not doing anything is clearly worse.
Yeah, it’s true that I wouldn’t want this to happen. My thinking was mostly derived from a European perspective, where people don’t sue "all the time" and there’s more onus on the accusing side.
I don’t think it would immediately have to result in this kind of situation you’re describing (and we both don’t want). I don’t want to debug legal ideas in lobste.rs threads, but I could envision different rules depending om platform size and media types (text forum vs images vs videos…).
I don't think it matters whether the liability would be enforced by private action or regulators, the destruction would be the same.
Online platforms have carve-outs for liability, e.g. Section 230 of the Communications Decency Act of 1996 in the US (and similar elsewhere, but that one is the blue print many of the others are based on.)
It might be useful to reconsider what constitutes such a platform: The idea is that because they're merely providing user generated content, they're not responsible - as long as they delete harmful stuff once they're told about it.
Is that still the case when their feed algorithms decide what is shown? I'd say that an editorial decision like that (no matter if made by a person or an algorithm) should come with editorial responsibilities, too.
Section 230 was based on common carrier laws. These made sense: the postal service is not liable for the contents of parcels it carries. If you send illegal drugs via the post, you are 100% liable, not the post office. The same applies to the telephone network. If you plan a terrorist act over the phone, the phone company cannot be charged as a conspirator.
Common carrier liability exemption comes with a legal requirement that you must be neutral. You must carry any parcel / message / whatever without reference to its content. You may not prioritise messages based on content (you can charge more for heavier parcels or for faster delivery, but you must make those charges uniform).
I am completely happy with the common carrier rules.
But the ad platforms like Facebook and X are not common carriers. They are publishers. They choose what to amplify. They block people who have not violated any law. They should be liable for any illegal or harmful content that they distribute.
That's what I'm saying. The feed is on them, but they hide behind "that counter-point to the anti-democratic deluge we're putting in front of everybody is just as accessible - if you know and bother to access it directly" to pretend that they're still common carriers. Hitchhiker's Guide, basement, leopard, something something.
I don't think it's correct that Section 320 was based on common carrier laws. I haven't seen it in what I've read of the contemporary debates or records like Kosoff's. The Telecommunications Act of 1996 that included Section 230 classified the internet as a Title I "information services" rather than a Title II "common carrier services". The reclassification didn't start until the FCC's Open Internet Order in 2015.
The explicit goal of 230 was to avoid the consequences of Stratton Oakmont that held Prodigy liable for user content because they had moderated. You can read it in the Congressional Record at the introduction of the Cox-Wyden amendment that became Section 320. It is very specific and prescient:
This description is the exact same argument @freddyb posted (and I replied to). If liability is imposed on internet communities as advocated, expect any surviving American internet communities to be bleached of any topic or opinion considered too complex or inappropriate for a preschooler in the most socially restrictive social group of the country.
But the solution there is not to repeal Section 230, but to improve it. Yes, repealing Section 230 would allow us to hold Meta, Twitter, YouTube, etc. liable, but it would harm everything else - including the sites we're discussing this on!
It only needs to be applied: Just reconsider if Facebook, Instagram, X, YouTube, ... are platforms or, simply by virtue of their editorial decisions, publishers.
The platform part can remain protected as platform as usual. The algorithm doing the "publishing" (i.e. front page, personalized feed, ads etc) and its output? Editorial control → editorial responsibility.
I don't even really know where to start with how much is wrong in this post.
No, Section 230 is not based on common carrier laws. Section 230 is based on an extremely broad conception of the 1st Amendment to the US Constitution, and on a strain of legal thinking that is repulsed by the idea that people might be punished for speech.
No, Section 230 does not care about "platform" versus "publisher" distinctions. Section 230 does not require that a site or service be neutral. Section 230 does not require that it be unbiased. Section 230 does not require that it be fair. Section 230 does not require that it be consistent. Section 230 does not even require that they try to do any of these things.
If I wanted to set up a forum and openly arbitrarily ban anyone or remove any post I don't like, at any time, for any reason including my inconsistent personal whim and mood at the moment, I would absolutely not be acting like a common carrier, but I absolutely would be protected by Section 230.
And that ultimately is the backbone of much of what we now take for granted about the internet. Without it, sites like this one simply would not exist, because the existence of moderation rules on this site would, under the prior Prodigy precedent, make the site be potentially legally liable for the contents of any posts the moderators choose to leave up, and the only safe way to play that game is not to leave up any posts at all.
This is a debate that has been going on for a long time over section 230 in the US. In short, the has US opted to treat online platforms as neutral carriers, like a phone company, rather than as publishers like a newspaper. If a newspaper publishes a libelous article, they are legally responsible for it because they have exercised editorial control. On the other hand, if a person says something slanderous over a phone line, we don't hold the phone company legally responsible because they are a neutral carrier, they just get your sound waves from here to there, they don't have editorial control. Treating the internet and online discussion boards as neutral carriers rather than publishers was one of the key factors that enabled forums and social networking sites to exist in the first place without the fear of being sued into oblivion for something a random member did before a mod got around to banning them.
Particularly for large platforms like YouTube, Facebook, Instagram, etc, it is logistically impossible to have a human vet every comment or private message or video. So the only feasible path forward if you held them liable for users' content on the platform would be to move away from an open internet with user content and towards a smaller number of vetted content producers and mass automated censorship, which would still not be adequate to prevent people from circumventing it or drawing people off-platform to be further radicalized.
The one area where I think the legal framework of "neutral carrier" is a bit less plausible is algorithmic content promotion. We know that companies with recommendation algorithms are doing a lot of subjective judgement calls about which content they want to promote and which content they want to bury. A Facebook feed that displays your friends' posts in chronological order is acting as a neutral carrier. A feed that uses a carefully designed algorithm that selectively promotes one political viewpoint over another or even one emotional vibe over another is starting to look a lot more like a publisher with editorial control than a neutral carrier.
They should be. I think that you only have social media platforms in mind.
There are online services and platforms that are not illegal, they just aren't suitable for kids. Betting sites for example. Or content that is just not appropriate for a 9 years old. There are many cases where as a parent you have to say, "no, this is not for you yet", and more and more of these cases are online in the last decade.
And who's going to decide what that is? The parents, who might be against the child's sexual orientation for completely invalid reasons? The politicians, who represent the parents more than they represent the kids? A 9-year-old LGBTQ kid should be able to find relevant content regardless of what their parents think. The Internet is possibly the best tool we've yet invented for liberating kids from their parents and other local authorities (self-appointed religious authorities for example). Let's not take that away from future generations.
While I agree with your goals, I don't think I agree with your points. You are asking the question but it needs an answer! Who will decide what is good for the kids when they cannot do that for themselves yet? You seem to suggest that the answer is "nobody" but while I have no references, I am pretty sure that is scientifically wrong.
Since no authority can be reliably trusted to decide what's good for kids, I think I'm willing to accept some harm in order to ensure that marginalized kids find what they need. But let's kill the worst of the harms, for everyone: the addiction loops, gambling mechanics, and algorithmic radicalization.
In EU countries, we generally agree that there are authorities that decide if our kids are fed properly, if they go to school as the law demands, if they are neglected, at what age they can drive, and buy tobacco, if they are allowed to carry guns, and many other things.
Maybe where you live is different, but remember, this is an EU directive, and it only applies to EU, so it probably doesn't affect you.
The EU "cookie law" affected my experience of basically every commercial website I go to. That is a minor annoyance; restricting traffic has much graver consequences and therefore demands much higher (IMO, insurmountable) standards.
"scientifically" wrong? This is a question of ethics not science.
I meant the question of what is better for the child, which should have a scientific answer.
Same difference. Science cannot answer questions about what is "better" for anyone.
True, like smoking, not everybody dies of cancer and some people really enjoy it. So clearly, for some people smoking is a net positive and science cannot answer the question for whom.
And this is why we should ban harmful things like smoking and pastries.
No, they definitely should not.
Different scenario then: A child suffering from physical abuse at home should be able to find resources on how to safely get out of that situation.
That's the type of service that requires no age verification by definition, isn't it?
One would think so. But then, giving kids such ideas could deprive "authorities" (such as parents) their God™ Given Right to exert discipline (behind closed doors), so who knows what happens when the 39% (to pick a number from a 2020 US study) "who had positive attitudes toward physical punishment" get in charge…
Good thing that it's not up to their parents in this case. Any decent country (and I would argue EU countries, with all their faults are decent) would make ensure that these types of online services and resources are not age limited.
I would bet that ALL EU countries already have phone lines where a kid can call and get help from experts, no questions asked.
Decent countries do not always stay that way. Germany's unfortunately up and coming fascist Afd party is explicitly against children's rights.
One should consider what bad future governments can do with a given technology.
By who's definition?
Keep in mind that this infrastructure is usable by anyone, not just people who think like you. Do you trust the definitions that Afghanistan would come up with? China? Pakistan? North Korea? America? Pick any other actor you want here.
It's an EU directive, applied to EU. Neither Iran, nor Afghanistan would like to implement something that gives so many protections to users, anyway.
Never mind Iran or Afghanistan, how comfortable do you feel about Poland and Hungary?
Can you explain what technical measures prevent these countries from demanding that the infrastructure built here is not used in their context?
Realize that it's a lot easier to get someone to flip a switch than it is to get them to spend months to years building infrastructure.
Well, a betting site requires you to pay money or connect a payment system upfront using a working bank account. I would guess that's a great age verification tool right there.
Gambling also takes the form of in-game purchases like loot boxes.
There's a difference between the parents saying it and some random enforcement mechanism that sends data to whomever.
Compliant sites can already provide guidance via https://rtalabel.org/ and have "parental control" enabled devices enforce it. Non-compliant sites¹ wouldn't bother collecting age information anyway.
There used to be more fine-grained schemas for age / audience appropriateness, but they languished. Could still be brought up again: have the data tell who is supposed to read it, then make the client make the decision.
¹ since you brought up betting sites: gambling is huge on the "ignore the rules" side of business
Most parents if not all, are even less aware. If you have teenage kids, you know that (if you're lucky, and if you're capable, and if you do have a good relationship with your kids) you have to learn about a lot of online "dangers" that never crossed your mind before.
This is the equivalent to saying that in the physical world, just label it ALCOHOL, ADDICTIVE, TOBACCO, and leave it up to the parents to decide if their kid is allowed to buy it. Parents have a huge responsibility, but they also need help.
If you check the EU blueprint, thy mention other, more fine grained attestations, but this out of the focus of my post.
Yes, betting sites have huge incentives to ignore legislation. This doesn't mean we don't have to add friction. The usual argument (which I also support) is that adding some friction by introducing huge privacy risks is not worth it. But it seems that in this case, privacy risks are very low to zero.
There are a few crucial differences between "physical" and "digital". The biggest for this question: in the physical world, "move" is free and "copy" is not while in the digital world, it's exactly the other way around ("move" is typically "copy + delete"). This means that when I present data in the physical world, the inspector (e.g. the cashier in the store that checks if I'm old enough to buy alcohol) would have to go through extra trouble to note down the information they received, while on a website, they have to go through extra trouble to "forget" the same information.
The accessibility risk remains rather high, though. Your "digital" example starts out with "An authorized issuer verifies your age once and issues a signed credential:"
Well… What happens if they don't?
If your local government refuses to give you a certificate you are entitled to get, then there are laws, and at least you know who to shout at.
What you describe is not much different than saying "and what happens if they refuse to give me a driver's license" in order to argue that anyone should be allowed to drive without a license. I respect if you believe there should be no government at all. That's practically what the intro says "If you think age verification should not exist at all", the rest of the discussion is pointless.
The German government recently proudly announced some driver's license app. It only works on "verified" devices, and they see no reason to change it.
Now, that's not a problem for driver's licenses, as long as the default is the plastic card thingy. But a friend of mine has an unlocked smartphone. I don't have a smartphone at all.
At 90% (or 95%, or 99%, doesn't matter) market penetration, they might well decide that having the app on your phone, talking to the car via NFC ought to be mandatory to track that only authorized folks can drive a car. For safety.
But what they really enforce is that you have a contract with Apple or Google.
A big problem in all that is that the politicians who drive such initiatives aren't exactly digitally literate. And as long as digitally illiterate busybodies like v.d.Leyen have a chance to perculate up the political food chain (she's big on the "think of the children" arguments and infamous for making a mess with her insistence that things go her way), I'm not interested in them having any say on how computing is supposed to work.
Separate reply for separate tangent: Websites can set up labels that aid parental control systems, and your claim is that this doesn't work because "most parents are not aware."
So you're assuming that kids will get devices that are, in some way, running an adult account, and not using Apple's Parental Controls, Google's Family Link, Microsoft's Family Safety or any other such mechanism.
What makes you think that these "unaware parents" won't just add their "I'm an adult" credentials to the account to make any complaints go away, either (or reuse their personal adult account on the kid's device. Or share the device, with no account separation - both of which amount to the exact same outcome)?
But as soon as they set up a "kids account" (and some systems are really pointing in that direction, e.g. ChromeOS: https://i.dell.com/sites/csimages/App-Merchandizing_esupport_flatcontent_Images/all/choose-chromeos-setup.png) , the system can do enforcement locally, no fancy data transfer required.
Basically you're arguing that parents are both too naïve to set up protections for their kids and savvy enough to set things up correctly for the age verification to verify their kids and not themselves.
Sure, you can do this. Every approach has its pros and cons.
I would love to see a comparison table between an attestation-based solution and a device-based solution.
One thing that I consider important is that a device-based solution depends on any OS working according to some guidelines, which favors the big established ones, both on mobile and desktop. An attestation-based solution places little to no burden on the OS and apps, which I prefer for various reasons.
Attestation-based solutions depend on the attester trusting your OS and app, and they will be content supporting a "some-9s" amount of platforms and ignore the rest.
Device based solutions depend on the parent making a choice that suits their parenting style, with the default options (that tech-illiterate parents would gravitate to) offering robust configurations out of the box.
For that reason I kinda suspect (with anecdotes supporting my suspicion) that building client-side restrictions places fewer burdens than having to appease some semi-central authority that has no interest in talking with you.
You'd still have to get the US on board, which seems unlikely. Or if you try blocking the harm that comes from the US, you get threatened with tariffs or abducted or something. Not to say it's not worth trying, but such a complex problem needs to be attacked from multiple directions.