Original author here:
Yeah a lot of the evergreening techniques (chiral switch, etc.) don't prevent anyone from getting the original, though of course doctors may try to switch you. The inhaler thing is double bad because of the CFC ban.
I didn't dig into the details of the fluticasone HFA switch, but my impression is that while it's obvious to replace the propellant, apparently you do need to do some engineering (e.g., on the nozzle) to make it work right. I don't know enough about what they actually had to do to know if the patent should have been granted or not.
It's fascinating isn't it? You'd never suspect that people are smuggling drugs out of prison, but the inhalers weren't the only thing either.
I'm not sure it's ever been looked in to, but having seen it first hand, I can tell you there's a whole hustle for people on the inside trying to get prescribed expensive drugs in order to supplement their meager existences.
> The only device mandates that should be taking place is for the default installations of web clients should be checking to see if parental controls are enabled. This only impacts the major browsers. An intern at each browser company could add this check in minutes. If they are enabled and the person logged in is on a regular account (not admin or power user of sorts) then the base installation of web clients must check for an RTA header [1]. If present, prompt for a override password and also give the option for the admin to approve-list the domain at that time. That's it. Not perfect, nothing is or will be.
It's useful to contrast this with the various device-based mandates that have been created in order to get a sense of what legislators seem to be trying to do. With that in mind, a few points:
* What you are proposing allows parents to opt in via parental controls, but age assurance mandates (both device-side and server-side) tend to require positive action to enter unrestricted modes. In some cases (CA AB 1043, for instance), this is just a matter of entering your age. In others, you actually need to demonstrate your age via some technical mechanism.
* While many age assurance mandates focus on adult content, which is primarily consumed via the Web, others (e.g., Australia's Social Media Minimum Age) focus on social networking, which is primarily consumed via apps, so anything that is Web only will not be effective.
* Site-level granularity isn't really fine enough in some cases. For example, the New York SAFE for Kids act prohibits certain behaviors such as algorithmic recommendations when a user is a minor, but doesn't require blocking minor usage entirely. It's potentially possible to implement this with something like RTA, but it would have to at minimum be at much finer granularity.
None of this is an endorsement of age assurance techniques; I'm just trying to help flesh out the situation.
> All legislation regarding age verification must revolve around this otherwise people must reject it as an abusive form of tracking and privacy invasion.
It's a bit late for that, given that around half of US states already have some kind of age assurance mandate.
It's a bit late for that, given that around half of US states already have some kind of age assurance mandate.
Perhaps late to solve this globally but parents can still install parental control software if they so desire and can still intervene locally to prevent sharing data with 3rd parties. At worst this means small children might not get to visit social media and other assorted sites and I am fine with that. I think a number of parents would be fine with that as well.
Sites can voluntarily label as some do. It just means that parental controls would have to default to blocking everything until approved and while sub-optimal maybe that's what people will have to do in order to avoid the evil pattern of sharing data with all the websites that will ultimately leak, or "leak", be sold, stolen, etc... Good parents will not participate in the evil patterns of sharing their children's personally identifiable information.
When the PII of children is ultimately shared with evil people the children once adults will resent their parents for not protecting them.
- To all parents here, your children have no idea what risks are out there including devious companies that want their data. They will one day be adults if all goes well. Protect your children as corporations and governments will not. They will thank you when they find out all their friends data was shared, leaked or otherwise abused forever.
Certainly parents can install parental control software, but what does this have to do with children's PII being shared with sites?
Just so we're on the same page, the way AB1043 works is that the OS determines the user's age and then shares the age bracket with apps. No PII is shared with sites (this is not to say that the age isn't sensitive, but it's not PII as usually regarded). Is your concern here that sites get access to children's information because children visit certain sites regardless of legislation? That's a real thing, but it seems mostly orthogonal to age assurance.
Certainly parents can install parental control software, but what does this have to do with children's PII being shared with sites?
The parent can block or just never approve all the sites that require PII.
but it's not PII as usually regarded
We will never agree here. All the companies I worked for financial considered any attribute of the person to be PII, even their IP address. We were audited very strictly on this. If a users age was disclosed to a third party without their written consent that was a contract violation and came with severe monetary penalties. Parents should expect this to be the minimum standard. It's their children, not the corporation or governments children.
Thanks for your explanation. I understand what you're talking about, but this all just seems to be entirely orthogonal to age assurance mandates, which are largely about controlling which content and experiences minors engage with, in many cases regardless of what parents want.
Again, this isn't an endorsement of these mandates; I'm just saying that what you're proposing here doesn't address the objectives that policymakers who are in favor of these mandates are trying to achieve.
doesn't address the objectives that policymakers who are in favor of these mandates are trying to achieve.
Oh trust me, I get it. They and I will never align. I know I am beyond beating the dead horse. It's gone from bone dust to micronized dust to sub-atomic particles to sub-quantum particles at this point. That poor horse will never be forgotten. Perhaps it is an illness on my part but I will find a way to bring this up every time until the year 2150 after which point this will be the least of anyone's concerns.
This is one of those situations where it's necessary to be very precise about the security properties.
Specifically, if you bind authentication to the connection, then an attacker who impersonates the server (in this case because it's the first connection, but in other settings because they have a fake certificate), then client authentication is not portable to another connection, so the attacker can't mount a classic MITM attack. However -- and this is a big however -- that doesn't mean that there aren't serious security problems. For example:
* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
* If you download some file (e.g., a script) from the server and then trust it, the attacker can use that to provide a malicious script.
>* If you use SSH to copy a secret such as an API key to the server, then the attacker still knows the API key.
That's much harder to pull off though, because you need to replicate the environment close enough so that the victim doesn't suspect anything. Do they put their config files in /var/lib or random docker volumes? Do they use docker compose or docker-compose, etc.
If you know its their first connection to a fresh VPS and assume they haven't used a web-based display to set up anything yet, you just need to guess their install image, which is probably off-the-shelf.
To add some color here:
It is very helpful to have someone pace you so that you can run an ideal pace without worrying about whether you are running the right speed. However, the rules require that pacers start with you [0], which means that by definition if you are running faster than anyone has ever gone before you have to run some of the race alone.
However, because marathon are often mixed gender and the best male runners are significantly faster than the best female runners, it is possible for a woman to be paced from the gun to the tape by a male runner. For this reason, there are separate records for the women's marathon for women's only events.
[0] This is one of the things that made Kipchoge's original sub 2 result not record-eligible.
- As a practical matter, anything that is a Proposed Standard RFC is a standard. In principle, there is a two-level system with PS and Internet Standard (down from three levels) but most WGs don't bother to advance specifications past PS. For example, TLS and QUIC are both PS.
- RFC 9580 obsoletes RFC 4880, so from the perspective of the IETF, it supersedes it. Of course, this doesn't make people do anything.
I didn't dig into the details of the fluticasone HFA switch, but my impression is that while it's obvious to replace the propellant, apparently you do need to do some engineering (e.g., on the nozzle) to make it work right. I don't know enough about what they actually had to do to know if the patent should have been granted or not.
reply