This requires a lot of extra work though, and extra work is downward pressure on the behavior (underage people looking at pornography) that the state of Utah is trying to exert downward pressure on.
The inability to immediately and perfectly eliminate a behavior is not a good enough reason to be against any attempt to eliminate that behavior.
> The inability to immediately and perfectly eliminate a behavior is not a good enough reason to be against any attempt to eliminate that behavior.
So if you are legally required to block all VPN users and then fail to actually block all VPN users what is stopping you from being punished for not complying with the law?
Nothing. Making laws that are impossible to comply with, then selectively enforcing them, is a favourite tactic of fascism because it allows you to imprison anyone you want, arbitrarily.
Not sure what the impossibility is. VPN's have a set of exit relays. If traffic is coming from one of those exit relays, it's coming from a VPN, so adult websites can be required to block traffic from those exit relays. What am I missing?
The law likely violates the U.S. Constitution’s prohibition on passing laws that significantly burden businesses and people outside Utah’s borders.
SB 73 burdens the rights of all internet users outside of Utah because it requires adult websites to either know every visiting user’s physical location, and then block those in Utah, or to verify every visitor’s age just in case they might be in Utah.
It's technically impossible to both implement Utah's law and respect the constitution. To make it technically feasible you'd need to either change the constitution or federalize the law.
The law is only meant to apply to citizens of Utah though. Blocking all exit relays would mean that absolutely anyone accessing that website would not be able to do so from a VPN which burdens people outside of Utah too.
This is what I was missing. Demanding that porn sites block VPN traffic (or only accept residential traffic) would mean that everyone everywhere using a VPN gets blocked not just in Utah.
I still suspect there's some kind of solution. Like Utah could tell VPN providers that if they service a customer in Utah then the VPN provider can't route traffic to adult sites. Or put the burden on the VPN provider to do age verification if porn is gonna be available through the VPN.
Come to think of it, I'm still a bit confused as to why VPNs are even relevant because it would seem to me that age verification would be done through some kind of having-credit-card type scheme which VPNs are entirely irrelevant to. I even read the article and I'm still confused. Oh well.
| An individual is considered to be accessing the website from this state if the individual is actually located in the state, regardless of whether the individual is using a virtual private network, proxy server, or other means to disguise or misrepresent the individual's geographic location to make it appear that the individual is accessing a website from a location outside this state.
But how can any site check if a client is a) a VPN client (typically this can be known because VPN exit node IPs can be learned), __and__ b) in Utah?
The impossibility lies in (b). Effectively this forces any affected companies having a nexus to the state of Utah to forbid VPN clients. I think that's a bit too far-reaching. It would be much more practicable instead to ask VPNs to disallow Utah client exits to affected sites w/o age checks -- VPN services aren't free, so VPNs basically can do age checks.
Given that this could have been written to be feasibly implemented, either this text was written to cause a controversy, or this text was written by people who don't know how things work. Either way, this text cannot be enforceable as written. The Utah legislature can easily modify this to be enforceable (see above), so it's not like a court striking this down might be playing partisan games just by striking it down.
You need to understand that my branch considers Catholicism to be a pagan shame and the Mormons an actual sex cult. We just don't talk about our differences anymore because it always ended in death.
The difference is, there are a reasonable number of churches that recognize Catholic or Presbyterian as Christian, even if it's not all of them. Only LDS consider LDS to be Christian.
But don't they still believe in other Christian texts, the same concepts, and the same god in the same way? It's probably more different than most other branches but it still seems like Christian DLC to me.
I think they do in some ways. But they're not generally considered part of the wider Christian church. Perhaps unfairly but I think that's how it's considered.
Christianity as a whole began as a cult of a cult of Judaism and so Mormonism began as a cult of Christianity, and all of it is several cults removed from Zoroastrianism anyway, with a bit of Greek and Roman paganism for flavor. Arguing about which is "more legitimate" is as ridiculous as debating how many angels can dance on the head of a pin. A thousand years from now, assuming humans are still around, they'll probably be worshiping the Omnissiah or something.
It surprises me that Americans are so untrusting of Mormonism since it's such a quintessentially new world religion. You'd think that a ruthlessly capitalist and hierarchical brand of Christianity where the center of God's kingdom isn't someplace in the Middle East but the United States would appeal to American exceptionalism. They even banned black people and called them cursed by God until the 1970s. Mormonism embodies the American zeitgeist more fully than any old-world religion, it's a wonder it isn't more popular.
Maybe it's the magic underwear that creeps people out?
"It's complicated." I'm not LDS and haven't been a member of the Christian sect I was raised in for many years. I've had besties who were LDS, though, and we talked a lot whenever it came up in conversation. (Which tends to be surprisingly often, FWIW.)
The gist is that LDS members believe that the Bible is true when it has been correctly translated. But that's a gap big enough to drive a truck through. There are some very real irreconcilable differences between the Bible and the Book of Mormon.
For example, Mormons believe in the practice of "sealing"[0], which is basically marriage that lasts for eternity. However, Jesus himself explicitly says in the Bible[1] that this isn't so:
> The same day the Sadducees, who say there is no resurrection, came to Him and asked Him, saying: “Teacher, Moses said that if a man dies, having no children, his brother shall marry his wife and raise up offspring for his brother. Now there were with us seven brothers. The first died after he had married, and having no offspring, left his wife to his brother. Likewise the second also, and the third, even to the seventh. Last of all the woman died also. Therefore, in the resurrection, whose wife of the seven will she be? For they all had her.” Jesus answered and said to them, “You are mistaken, not knowing the Scriptures nor the power of God. For in the resurrection they neither marry nor are given in marriage, but are like angels of God in heaven.
Personally, it seems exceedingly unlikely to me that each one of the translations on the linked page are wrong in exactly the same way.
Anyway, that's why lots of LDS will say that they're Christians. If asked, they believe that the Bible is true where correctly translated, but in my (admittedly) limited experience, not many of them as a percentage have actually read the Bible themselves to know what it actually says about this. It's also why a lot of Christians say that LDS are not: they believe in lots of things that are not in the Bible, and believe that the Bible we have today has lots of mistakes.
NB: I'm not staking an opinion on any of this, or taking sides on the matter. I'm offering this in the same sense that I might share something I learned in history class about the French Revolution. It's interesting to read and learn about, but doesn't directly affect me and it's not anything I want to participate in. Especially do not take this chance to explain to me why the whole "left his wife to his brother" thing is f'ed up by modern standards.
I would think that requiring adult websites to essentially block all VPN traffic to be pretty heavy handed and hardly a solution. Especially considering there are many reasons to use a VPN.
It's impossible to have a full and complete list of VPN exit nodes, for the simple reason that no company publishes the full list, and also technically if you set up an OpenVPN server on digital ocean and connect to that you're also using a VPN but no one would know your address is hosting a VPN server.
Utah could demand the moon, it doesn't mean that the federal government would agree they have a right to that demand.
Utah can't tell businesses that service the country (or the world) how to do anything in this regard. You can't demand a list of the VPN exit nodes, because no VPN would ever give you that, and if they're outside of your jurisdiction, how could you possibly enforce it (assuming you got the Feds to agree with your law regulating interstate/international commerce now). You can't tell websites to only accept residential traffic, for the same reasons.
The internet sorta fucks states rights (in a good way).
Why would a VPN company care about what Utah requires if they have no legal presence there(or in the US for that matter)?
Besides, there's no such thing as "residential" IPs. If I set a VPN gate at my mum's house, how would the porn company know?
The "impossibility" is in them saying "we cannot guarantee with 100% certainty that the user isn't using a VPN" and that's correct, they can't - but the law has no provision for that, they are risking fines over something they cannot control.
You'd have to ask every non-residential host online to do the same. As above, you can get a DigitalOcean droplet and ssh -D to it, now you have a SOCKS proxy that for state's concern is doing the same as a VPN.
Probably that “all VPNs” and all commercial VPN providers are two vastly different things. You can literally just make your own VPN if you have access to hosts on two different networks.
In a high trust society people aren't trying to con you but they're still subject to structural constraints. When Alice has a good idea but Bob has a monopoly, Alice isn't allowed to implement it and Bob doesn't understand it because he's not smart enough to rather than because he's crooked. When a monopolist has a stable source of revenue their management is living in a world where money is available and they start thinking up ways to "help" by spending it, which raises costs even when it's well intentioned and then harms the poor who now have to pay a premium to receive a necessity.
Structural constraints aren't exclusively a problem because they enable corruption. There can be incompetence without malice. All it takes is for someone to be well-intentioned but incorrect, or for the system to allocate rulemaking authority to someone without the information necessary to make the best decision.
The classic example is a large hierarchical organization where the line workers have knowledge of the process but no management competence and correspondingly don't know what information is even relevant to pass up the chain, and the top brass have management training but have been put in charge of so many people that they don't have the bandwidth to know what's actually happening on the ground.
I am aware and mostly agree with the dogma about how decision-making power should be delegated to those with the most relevant information to that decision. In fact, that to me seems a bit tautological and beside the point.
My point is essentially that there are situations where a monopoly is the best system available especially if you can rely on those involved to act in good faith. For example, I think the government holding a monopoly on policing power is the best available system. Within that monopoly power can be delegated a whole manner of ways, but ultimately the public good of policing is distributed through a manner of sub-institutions all answerable to a single institution.
I think the real delta in our views is I see the values of the people within a system as of equal or more importance to the structure of the system itself. It seems to me that you reason about this topic in an almost purely abstract manner, attempting to posit a "perfect" system which could work no matter who was actually implementing it, and indeed would be the best no matter who was actually implementing it. I used to think this way, but came to the conclusion that it was impossible.
Banning hardware and banning software are very different things, and the latter is orders of magnitude easier than the former. Physical and non-physical things are different!
I thought his points were legitimate and well argued. I think that it's very easy to say "X should be unrestricted". I also think that eventually one of these models will be used to do something truly destructive and insane and that some level of "compelled responsibility" to the open-weight model ecosystem is inevitable.
We are not talking about chainsaws and excavators, we are talking about LLMs. LLMs have different risks in terms of scale and kind and must be considered differently.
I've read some allocator walkthroughs before but I thought that this line stood out:
"to get individual free() working, the allocator needs to remember something about every allocation it handed out. and that’s the moment metadata stops being optional."
That's just a very nice distillation of an important concept.
This becomes particularly important when the allocation and metadata cannot (or should not) be stored in the same address space. An example of this is allocating memory on GPUs.
The conventional approach for allocating memory on GPUs for games and other applications is to use a real-time allocator such as TLSF. However, it is not usually discussed that TLSF is real-time because it stores metadata in-band. It is possible to create a variant of TLSF that preserves its real-time properties while storing metadata out-of-band, but this requires careful consideration.
If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important.
Something I noticed is that _very often_ the code that is calling malloc(n) is keeping track of n somehow for its own reasons (bounds checking, grow/gap pointers, etc) so merging the value halves stack churn and it’s an easy win.
>> If you can convince the caller to keep track of that metadata themselves you obviously don’t need to. That can be important.
> That's why C23 introduce free_sized
Is it? C23 still has free, so there’s no guarantee callers wil use free_sized, so the allocator still has to be able to obtain a block’s size from a pointer.
Because free still exists and there is no “allocate this number of bytes of memory; I promise to free it with a call to free_size” call, you can’t have a malloc implementation that doesn’t track block sizes.
I think the only thing free_size adds is robustness. Allocators can check the passed in size with what they know and abort the program if they do not match. That can thwart some security issues.
> keep track of that metadata themselves you obviously don’t need to
likely it'd a be perf. hit in most cases. They'd have to copy to the tail end (likely) of the allocated area. Or the start and offset the pointer, they'd need to know the size of the metadata and account for that, including aligning it.Hence, the tail feels 'nicer'
It's possible to manually use mmap and forgo malloc entirely, rolling your own arena manager.
Well, even that doesn't really work, because optimized allocators typicallly don't allocate exactly the amount that you ask for, they allocate some larger chunk to help with both alignment and fragmentation.
So, most likely, there are two sizes in reality: the size of your user data that you care about; and the size of the memory chunk in which your user data resides, that free() cares about. So, unless you're willing to go for an API like this, you can't rely on the consumer:
int* ptr_to_dest = NULL;
size_t size = 10 * sizeof(int);
size_t allocated = malloc(&ptr_to_dest, size);
if (allocated <= 0 || !ptr_to_dest) {
//handle allocation error
}
//... use ptr_to_dest, size
free(ptr_to_dest, allocated); //careful not to pass size here!
Actually yes, the malloc/free API (inherited from the ALLOCATE and FREE statements of PL/I) is too simple.
The metadata that malloc always attaches to the allocated memory would normally be useful for the user (i.e. having access to values like the currently allocated size and the total size of the allocation).
Very frequently, the user must duplicate inside the allocated memory the same information that already exists in the metadata, wasting memory. Also time may be wasted with requests for reallocation, instead of just adjusting the currently allocated size, when this is sufficient.
With a better API, the metadata would have been visible for the user. Being hidden from the user is not a protection in a language like C, where using pointer arithmetic can trash any memory location. Being exposed as non-mutable would have been a better protection.
Moreover, a better metadata structure for malloc should have always included a reference count, to be handled automatically by the compiler, and the malloc/free functions should have been invoked only implicitly, never explicitly.
To play devil's advocate, the problem with exposing more info is you limit the allocator design space.
1) If the app knew about and could use the additional underlying capacity, memory checkers wouldn't be able to find small overflows
2) Calling realloc instead of knowing existing capacity doesn't really provide better performance, at least not asymptotically.
3) If you need to know the requested allocation size, usually its for a dynamic array. Constantly requesting the size from the allocator would often have horrible performance if the size wasn't stored in adjacent metadata, but instead required a lookup operation, as is the case with hardened allocators. In practice hardened allocators probably wouldn't be a thing, or alternatively it would be idiomatic to store the size separately anyhow.
4) Reference counts would impose significant space and layout limitations despite most allocations never needing it.
There's another group who would argue the allocator should require passing the size and alignment to the free function, so allocators can be optimized better. Most of the time this is known statically. I think C2y will add APIs like this, though there's also a proposal to standardize an interface to query allocation capacity. Altogether I wouldn't be surprised if someday people appreciated the balance struck by malloc/free/realloc, especially as a minimal interface for overlaying application-specific allocators or injecting instrumentation. It has a certain elegance, in the sense of nothing left to remove.
