This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.
Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.
We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:
-
Shaming.
-
Attempting to 'build consensus' or enforce ideological conformity.
-
Making sweeping generalizations to vilify a group you dislike.
-
Recruiting for a cause.
-
Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.
In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:
-
Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.
-
Be as precise and charitable as you can. Don't paraphrase unflatteringly.
-
Don't imply that someone said something they did not say, even if you think it follows from what they said.
-
Write like everyone is reading and you want them to be included in the discussion.
On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.
Jump in the discussion.
No email address required.
Notes -
The cost of compliance -- which is to say, the reams of paperwork and signoffs necessary -- will make this impractical for startups. The large companies making this stuff will do it -- eventually, with the UK getting delayed releases. The Chinese knockoffs will continue to be sold unlawfully, and a lot of new stuff just won't appear in the UK at all.
Sneer all you want (I guess you're a Real Engineer), but I think a big reason bits have continued to grow while everything else has stagnated is the regulators haven't caught up with the bits yet.
Presumably bits continue to grow because you can throw more bits faster these days, compared to 5 years ago. That seems like a field that hasn’t stagnated.
More options
Context Copy link
I've thought about this a lot in trying to bootstrap something in the bio space. Even if I moved to Prospera tomorrow to escape the oppressive FDA, the CapEx required to get something off the ground is absurd. Simplest of animal studies is 10k a pop for really simple studies and more like 50-100k for the real disease relevant models, renting a single lab bench a month for myself is ~3.5-5k (maybe cheaper now that the biotech market has cratered), basic reagents run from a few thousand/month to 10s of thousands depending on what you're doing. Anything with human cells necessarily requires a bunch of infrastructure to do cell culture. There's also very few projects that lend themselves to producing an MVP and moving some units to fund more R&D; these are all decades-long slogs.
I joined a bunch of DIYbio mailing lists, discords and slack groups and the kinds of projects they do are just sad. More fit for high school ed than tackling any real problem.
The fact that you can buy a nice desktop for a few thousand and hack away in a fetid, windowless apartment for a few months or years to build a functional product seems to uniquely support innovation and, most importantly, give aggressive young founders a chance to lead a company. I'm interested to see whether the shift to training giant, prohibitively expensive AI models will lead to the same dynamics we see in biotech.
More options
Context Copy link
My read is that they literally just need to fill in that table that I mentioned on page 32. That's not a lot of reams.
I am most decidedly not a Real Engineer.
Like I mentioned, we will see if the economy of bits will grind to a halt... or if they'll take the couple days necessary to not have a default password and to write "Yes, we don't have a default password" in the table on page 32. Perhaps you could formulate your prediction in numerical terms? Maybe something about growth rates in the tech sector over the next ten years? Maybe something about stock prices and how they'll reflect this immense stagnation? Or maybe an explanation for why the market hasn't already priced this in and had a massive drop in valuations in the past week in response to oppressive new regulation?
I don't think you understand how this works if you think that this is the only necessary step once this becomes an obligation by law.
Since this is a potential liability, someone will have to be responsible for filling that form, and they'll also have to have sufficient means to enforce that the form is true. That person is most likely a lawyer and not technical themselves, which means they'll have to rely on auditors, which means not only that you'll have to pay money to get those audits done, you'll also have to find a company that will do them on the tech stack that you are running and is familiar with the intricacies of the particular legislation you're trying to abide by.
And once the bureaucratic machine gets started like this it doesn't stop, standards will get more complex, there will be people whose whole job is to ensure that they are followed and the costs will balloon accordingly.
Compliance is a huge industry. If following the law was that simple, it would not be.
Like Bastiat says, there is what is seen and what isn't seen.
What is seen is the valuation of established companies that have compliance departments and who'll be able to integrate regulation with a marginal cost change they can pass on to the consumer. What isn't seen is how much harder it is or will be to get funding for a startup that designs novel appliances because the costs to enter the market are now higher.
Weird. I hear about that from my friends in literally every other industry ever. They still seem capable of operating.
I'm always sympathetic to concerns of regulatory capture putting barriers to entry in front of small businesses. Totally agree that this is the single strongest argument against these types of requirements. I just doubt that these particular requirements are that onerous. Plenty of smaller shops that actually care about not being a security clusterfuck already do these kinds of things, and you can do most of them without too much difficulty as a hobbyist. In any event, if you're a start up that can't figure out how to not have a default password on all your devices, I actually kind of don't want you selling stuff, anyway.
Eh... they vary a lot, both on context and use case. Requiring secure storage for persistent storage of security parameters (5.4-1) makes sense and has trivial cost for applications like a network storage device, but it'd break a lot of assumptions on FRAM-heavy low-power devices, and that rule notably isn't conditional or a mere recommendation -- perhaps they didn't think about FRAM, or other persistent memory, but I wouldn't bet against UK compliance checks taking that as an excuse. Making security-focused unique IDs tamper-resistant (5.4-2) isn't too bad on a device with a real MAC (though not costless; there are benefits to software-changeable settings here), but for the more ultra-small or ultra-disposable equipment that's largely going to mandate more and more of program flash be devoted to encryption keys (unless you want to decrypt something on discrete flash every time you're doing an update check). Mandating a network update happen over a trusted relationship (5.3-10) and be timely (5.3-6) and be automatic (5.3-4) isn't too bad for a situation like deploying a bunch of wifi access points or phones, as much as I hate 99% of implementations work, but it's an absolute mess for wide deployment public LoRaWAN devices, and a mess for things like CAN- or LIN-networked embedded devices.
Others vary heavily on interpretation. Mandating that "For constrained devices that cannot have their software updated, the product should be isolable and the hardware replaceable" (5.3-15) could mean almost nothing, or it could require vendors to commit to support any optional part of a product until they retire an entire series. And these all definitely kill EPROM devices that it covers -- I'd expect this ends up with a ton of explicit or implicit exceptions, mostly around the "On devices with several microcontrollers (e.g. one for communication and one for the application) some of them might not be updateable", but it's not really obvious from the text.
That gets worse if they start dialing Mandatory-Conditional or Recommended rules into plain Mandatory ones down the road, and a lot of the text suggests that they're planning it:
In particular, SecureBoot (5.7-1), hardware memory access controls (5.6-8), and guaranteeing cryptographic updates for the life cycle of the product (5.5-3) mean throwing out a lot of existing microcontrollers, microprocessors, and often related code. It's clearly intended for big GHz+ microprocessors, but there's a lot of new (mmu'd!) chips that don't have this capabilities. SecureBoot there's some arguable conclusions for some of the bigger devices, like throwing a ATECC608 after a PIC, but a) I'm not sure if that actually complies with the recommendation, and b) no, god, no. Hardware memory access controls... maybe ESP32 memory protect would cover it (though they're software-settable, though the software settings are code-private?). Wherever these hit, a lot of chips aren't going to pass it, and businesses focused around them are going to have to toss inventory and code -- there's just too much of this stuff that isn't portable.
A number are probably gonna have to start now on the off chance that it happens in a couple years.
Now this is the type of response I was hoping for! Actually engaging with the substance!
Perhaps they'll issue a clarification, but from the note in this section, I think someone could read this as "memory"; it has "memory" right in the name! In general, I do expect there to be some clarifications along these lines as folks like you bring up additional concerns.
This one is conditional, and I imagine ultra-small or ultra-disposable devices won't qualify in the first place.
Same here; conditional. We'd at least have to get down to the level of thinking about each of the devices you've mentioned in terms of the conditions.
Notice how they define isolable:
In the section describing the rule, they continue:
I think I would interpret this as, sure, you need to support any part of a product until you tell the customer that you're not supporting it anymore, and the type of support can vary.
Yeah, I have a feeling that these aren't going to pop into the Mandatory category for a while. The real good news is that concerns are really of the type, "Will they at some point make these Mandatory, when it is still too soon?" Because pre-rule-dropping, I imagine the worry would have been of the type, "Will they make this stuff Mandatory now?" And, they, uh, didn't. I think this document shows a pretty decent level of care in getting some of the really basic stuff right and showing the industry the direction they'd like to go in the future. There's no telling at this point whether it'll all actually go that way; one has to imagine that there are differing worlds where it seems more/less plausible to upgrayyyed these Recommendatations into Mandatory.
Whereas this one, I think is fine, given their explanation:
How easy is that? You don't even have to update it at all. But if you do, then at least make sure your shit isn't trivially broken, at least so long as you're telling the customer that you're still supporting it.
Maybe, but so does CMOS RAM, and that's a central example of where you probably do want this rule to apply, and it's (usually) more volatile than FRAM. 5.4-1 to my read isn't about access modes or media type, but about storage volatility, and that makes some amount of sense for certain attack vectors -- you don't want someone reading cloud passwords by probing random SPI flash, as weird as that particular threat is.
But it also makes a lot of design spaces for low-power devices goofy, in ways that don't make sense. There's probably a class of low-power device where it's a really critical security problem is someone delid the main processors and inspects individual FRAM cells during a toggle-off state, but 99% of the time even if someone could hijack a session id from that it's less big of a deal than having access to the board to start with.
Yeah, but the condition is only that applies where ever "a hard-coded unique per device identity is used for security purposes". I think that includes virtually every LoRaWan (DevEUI) and probably every LoRa device, for one common example, but also technically at least most Bluetooth implementations. There's other places where it's a good idea to use hard-coded unique identities per device for security purposes even where it doesn't 'matter', and that's largely going to result in people just dealing with stupid hacks instead to avoid triggering the requirement whenever possible.
Yeah, but the conditions for 5.3-4 is "an update mechanism is implemented", 5.3-6 "an update mechanism is implemented" and "the device supports automatic updates and/or update notifications", and 5.3-10 that "updates are delivered over a network interface" and "an update mechanism is implemented". These are fine when you're talking a full web-UI/app-equipped device, but twenty sensors on a LIN line that can be updated still hit the requirement for 5.3-4, which is on its own a requirement for automatic updates so you now hit 5.3-6. Then you're trying to figure out how 5.3-10 works for devices that don't have user interfaces (and may not have user physical access!), and now you're either stuck tossing an authentication layer on your LIN, implementing a cryptographic security function for comms on said LIN, or spamming users with update notifications like they were running Arch Linux.
Eh...
Let's take the example of a lightning switches attached to a base station, as a fairly common home automation setup where the switches and adapters are... not actually a central case of the constrained device model (they have wall power!) but are at least arguably close. If you build one of these, you're probably going to support a wide variety of light bulb sockets and switch types, but not all of those are going to make sense over the longer term -- maybe a socket type falls out of popularity, or a new lightbulb tech drops that doesn't play well with dimmer circuits, or a vendor you partner with stops selling a product that makes that particular device make sense.
By the text, is a lighting hub "isolable and hardware replaceable" if the vendor doesn't want to sell every attachment for the hub's life cycle? Removing one attached device doesn't make the attached device 'isolable', because turning on and off that light is its core feature. Nor is removing the entire hub from the internet, since there's no sane way to call that a "self-contained environment with other devices if and only if the integrity of devices within that environment can be ensured", when the especially if the entire reason to pop them off the internet has to do with their ability to communicate securely with the local hub. Would it be hardware replaceable is the only hardware replacement doesn't actually fit into the same socket, just because something attaches to the same hub?
Yes, in practice your interpretation is the sane one, and hopefully it's probably going to end up as the sort of asterisk that just confuses people, like vendors just putting out generic 'support may stop without notice for some devices' clauses. But at best that turns the requirement into aspirational text instead of the actual policy.
I think the interpretation of that standard is closer to page 45-46 here, if not on the exact same timelines, and that quickly turns into an eWaste and version hop mandate for a lot of stuff pretty quickly in order to theoretically prevent the plausibility of certain attack classes, rather than blocking trivial ones. But even for its steelman of "don't use WPA2-only chips in new products", I think it's still costly even if well-intended, and a lot of those costs don't make a ton of sense. There's a number of chips and equipment that can't connect on WPA3 at all, and even where it's something that can be implemented in software that doesn't mean it's exactly easy.
More broadly, though, it seems like overbroad application of a rule. A presumption toward encrypting everything makes sense when it's free or nearly-free, but there are a lot of entire devices where it's just not that relevant. If your equipment does literally nothing but relay temperature and humidity values over ISM bands, you might want some amount of authentication to prevent spoofing, but it's really not that big a deal if someone can listen in. And there's a lot of IoT stuff that goes into that category.
There's some parts of the rules that motion around this -- 5.5-1's "Appropriateness of security controls and the use of best practice cryptography is dependent on many factors including the usage context" or the exceptions for ARP, DHCP, DNS, ICMP, and NTP in 5.5-5 -- but again that turns the requirement into aspirational text.
Fair enough. Hopefully the worst case is that this ends up not being covered, even though it should be.
I think I can agree that there may be tradeoffs here for some devices.
I think these would almost certainly just be classified as "constrained devices", and they also give alternate mechanisms for valid trust relations, which I think will be what the automakers go for. They'll do the verification at a different step and say that the lack of physical or other access is what ensures that presence on the network is sufficient.
I think you're right that some portion of this is aspirational text, but I think it's along the lines of, "If you can just put some reason down on the table for why this should be considered aspirational text, then you're probably fine," and the only people who are at risk are the people who are doing the clearly and obviously boneheaded stuff. Like, I don't think it's going to be hard for the maker of a device that does nothing but relay temperature and humidity values over ISM bands to just say, "It's a constrained device; can't do any of that fancy stuff; pretty much no way in anyway," and we can all mostly go home happy. If we start having major corporate networks brought down by botnets of temperature monitors (uh, how?), then perhaps folks will have to figure out how to make it more than aspirational text.
In any event, thanks a bunch for really thinking through edge cases for a wide variety of really specialized and, for lack of a better term, really constrained devices.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
In the specific case of the UK, most industries are not doing well, I believe in part due to a regulatory environment that makes it very hard for anyone to do anything.
More options
Context Copy link
Sure, and Harrison Bergeron could walk with a junkyard's worth of scrap metal stuck to him. It's a handicap, not necessarily a fatal one (though sometimes it is).
More options
Context Copy link
Where is the innovation in any other industry over the past decades exactly? You know, since they brought these in.
How expensive is it to build a bridge now, versus a hundred years ago, adjusted for inflation? "capable of operating", what a joke.
As Kulak is fond of saying, the reason we don't have flying cars isn't that they haven't been invented, it's that they've been made illegal. They were commonly flown (and shot down) by teenagers in the 1910s.
This is the tired same equivocation that motivates all such regulatory barriers. I complain about having to fill forms, you retort about the justifications for the form existing as if I didn't also have such a concern.
There are other answers to the problems of humanity than increasing the size of the bureaucracy. Just no other that fits into managerialism.
what do you mean by this? A homemade airplane isn't the same as a flying car. I guess it could work if you live in a very rural, but the problem with airplanes is that you need a long runway both to takeoff and land, plus clear airspace. That makes them impractical for anyone living in a city. A flying car could theoretically fit in your garage, take off/land vertically, and fly carefully enough to avoid collisions in the sky.
A Sopwith Camel fits in a garage and can take off and land on a piece of uneven land 300m long. And that's with 1910s technology. Central Park is 13 times longer.
The reason we have long runways for planes these days is because they are optimized for speed and drag, not lift. Which means they have weak landing gear and swept wings.
We had flying cars, we have the technology, they're just illegal to operate.
300m long is more than three football fields! That is an absurd amount of space for anyone in a city, where we fight over parking spaces that are about 3 meters long. The one @ToaKraka linked sounds better, but 75m is still way too much space for most people. You also need enough space in the sky for othem to fly without running into someone else, which can happen at any angle in three dimensions. It could work for a select few, but... we already have that, with private planes and helicopters.
Besides, if we're going this route, why not bring back zeppelins? The Empire State Building was designed with a spire so zeppelins could dock on top, as were several other buildings of the time.
I mean if we're talking theoretical numbers, in STOL competitions the world record for shortest landing is a little over 9ft, in aircraft that look very much like WW1 fighers or WW2 recon planes: high lift extremely light tuboprops. That part of the problem isn't really that difficult, it's more of an engineering and architecture problem than anything else.
The safety thing is the real reason, but valuing that over flying cars is parochial to the modern societies we live in. It's a cultural rather than physical limitation.
You might be joking but people keep saying that will happen since we solved most of the technical issues and helium isn't that expensive anymore.
The problem is that they're slow and their only advantage over planes is fuel efficiency and thus range. Making them only really suited for large scale transport where they don't have enough of an edge over boats or rail.
More options
Context Copy link
More options
Context Copy link
See also the autogyro/gyroplane/gyrocopter, developed in the 1920s, which can use 75-foot (25-meter) runways.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
Let's go with a simple one - the shale fracking revolution in the oil/gas industry. But nobody is actually going to go counting these things, because no one really has any sort of consistent argument for which sorts of regulations stifle innovation. Again, I totally realize that they do sometimes, in some ways. But what sort of massive innovation is going to be stifled by requiring devices to not have default passwords? Like, surely we can agree on that one. We could at least leave open arguments for other requirements, and I would welcome a wide-ranging debate on them. But if we're stuck with just theoretical arguments, totally disconnected from any specifics, in a way that can't capture basic truths like, "Being forced to not have default passwords is not a significant barrier to innovation," then we're not going to get anywhere.
Ok, so you also have a concern about default passwords. What are you going to do about your concern?
This isn't exactly a revolution. The tech behind shale fracking was known for quite some time, it just wasn't put to use because the costs associated with it meant that it was uneconomical. It wasn't a major shift or technological advance that unlocked shale, but an increase in the cost of energy and a lot of financial chicanery that made it competitive with traditional fuel sources. There's a very plausible case to be made that the technology is ultimately a loser, and that the environmental damage it causes in the long run will be more expensive than the economic value derived from the crap fuels you get out of it.
More options
Context Copy link
Since we are talking about the UK, shale fracking is illegal there. Hardly a revolution.
Irrelevant. Obviously, people can choose to regulate something specific away. The question is whether there has been "any" innovation in "any" other industry (that is, the non-bits ones that have more regulation). Unless you're claiming that the US has no regulation on the oil/gas industry, the shale revolution, which literally has changed the world at a geopolitical scale, is a huge counterexample.
But there are many others. Space X. Ozempic. Etc. It's really hilarious to have all the huge techno-optimists, who think that AI and tech more broadly is going to revolutionize literally everything, and at the same time, they imagine that the tiniest amount of regulation on fucking light bulbs will grind literally everything to a halt.
That you can scoff at the idea that regulation can kill innovation doesn't mean it cannot.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
That is a fair one, but It's also a very good example of just what I'm saying. I was part of the few people on the quite unpopular side of the oil industry here in Europe in the 10s when it was banned, for the same reason I'm on this side of this issue now.
If the UK wants to make such regulations it will reap the same sort of benefits: no toxic chemical pollution or chinese crap botnets, but also no innovation in these respective sectors.
It's a choice.
You can not like that enforcing common sense rules to an industry through state mandates is a barrier to innovation all you want. It's not going to stop being true. The debate is only on the magnitude of the effect.
I don't buy chinese crap that spies on you, I tell people not to buy chinese crap that spies on you and I shame people who do so in my social circles.
Hell, I've spent years of my life writing symbolic execution software used specifically to make edge devices secure, some of which you may be using right now. What have you done?
So, will you then make a prediction along the lines of what I asked for in the OP? Are you predicting that tech companies will pull out of the UK rather than either upgrayyyeding their security practices for the world market or going with a dual product (one version that doesn't make absurdly basic mistakes for the UK market and one that does make those mistakes for the world market)?
And I claimed that being forced to not have default passwords will have an incredibly low magnitude effect on innovation. Do you actually disagree with this, or do we agree?
I do the same, but clearly that is not changing much about the world. Have you succeeded in changing the world through your evangelism?
Then I'm sure you will be pleased that this work won't be going to waste by someone shaving a few cents off of the cost of your product by putting a default password on it. Honestly, hearing this, I'm really not sure what your concern is. Is it that your company's "We're Actually Secure" marketing is going to be slightly less effective, now that the floor has been raised? Did you really think that such marketing was really of all that much value in the first place? @The_Nybbler thinks that it's completely a waste and that no one would spend one red cent more for your secure product. Do you think he's wrong?
I can easily commit to saying that no major IoT startup success is likely to be based in the UK any time soon. But that's saying nothing given they're pretty much all American already for many other reasons.
Maybe some guy at Arm will have to add one more form to some pile or something.
Europe at large is a dying crab bucket that everybody who can make things is leaving because if you try you reap only taxes and lawsuits.
That's my concern. John Galt is my concern.
Yes and no. No chinesium lightbulb maker is ever going to bother with formally proving their code is correct because they don't care. But some connected things actually need to be secure so that you don't explode, catch on fire or get robbed.
I find the actually useful non gimmicky applications of IoT are in this latter category, and that for those the customer and the manufacturer usually know better than to cheap out.
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
I don't think the "detail" required is going to fit in that table. So it's going to be a reference to some much longer document which explains each item, in language understandable to regulators. And then all this will have to be reviewed by a lawyer specializing in UK regulations. And every time a change is made to the device, the document will have to be audited to ensure there's still compliance.
Of course just this one document isn't going to do much, aside from make new IoT devices less available in the UK and other countries adopting it as mandatory. The more regulation in more countries, the more the works get gummed up.
The good news is that it reads like they're expecting that companies will just publish this document on their website along with other support documentation. So, it won't be long until we get to see some and find out whose prediction is closer to accurate. As for the prediction of availability, would you like to predict anything specific about companies pulling out of the UK market?
If it's really so easy there won't be any problems. But I'm pretty sure, given the absolute glee expressed in your original post, you know it isn't.
I don't follow your line of reasoning. Can you speak plainly, please?
Your original post expresses considerable contempt for "tech folks" and demonstrates absolute joy for us having regulation "dropped" on us "in a much stronger way that you really won't like." This really doesn't fit with an idea that you think the regulations will be anything like easy or simple to follow -- rather, you actually think they will be difficult and painful to follow and are joyfully anticipating the pain it will cause.
Yeah, regulation sucks. It's terrible that in the "real" engineering professions, you need a minimum 10 years of experience before you're allowed to do anything more than turn the crank on well-tested models to determine if some very slight variation of an existing thing meets all the requirements, and then fill in all the boxes on the paperwork to maintain traceability. Doing that has high costs; applying those costs to the software industry as a whole will cause it to stagnate.
This does not follow. It's just a non sequitur. It can be easy and simple to follow, but incredibly grating to the personality of "artists". They don't like coloring inside the lines, even if it's easy and simple to follow.
Who are 'artists'? Can you speak plainly and say what you actually mean instead of sneering and generalising like this?
More options
Context Copy link
If it's that grating, it's not easy even if it is simple. The word for such a thing is common: "tedious".
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link
More options
Context Copy link