[{"data":1,"prerenderedAt":1029},["ShallowReactive",2],{"blog-post-en-what-is-cross-origin-opener-policy":3,"related-posts-en-what-is-cross-origin-opener-policy":141},{"post":4,"slugMap":140},{"id":5,"title":6,"author":7,"body":8,"category":105,"date":106,"description":107,"extension":108,"faq":109,"meta":128,"navigation":129,"path":130,"readingTime":131,"seo":132,"slug":133,"stem":134,"tags":135,"__hash__":139},"blog\u002Fblog\u002Fen\u002Fwhat-is-cross-origin-opener-policy.md","What is the Cross-Origin-Opener-Policy Header and Why Does It Matter?","EuroraCloud Team",{"type":9,"value":10,"toc":94},"minimark",[11,15,19,24,27,30,34,37,40,44,47,50,54,57,60,64,67,70,74,77,87,91],[12,13,6],"h1",{"id":14},"what-is-the-cross-origin-opener-policy-header-and-why-does-it-matter",[16,17,18],"p",{},"The Cross-Origin-Opener-Policy header, usually written as COOP, is a response header that controls whether your page shares a browser window relationship with pages from other origins. When set to same-origin, it isolates your document into its own browsing context group, so a page from another origin that opens yours, or that you open, cannot hold a scriptable reference back to your window. This closes a class of cross-origin attacks known as XS-Leaks and side-channel attacks, and it is also the setting that unlocks certain high-performance browser features.",[20,21,23],"h2",{"id":22},"why-does-the-cross-origin-opener-policy-header-exist","Why does the Cross-Origin-Opener-Policy header exist?",[16,25,26],{},"COOP exists because opening a window creates a link that can be abused. When one page opens another with window.open(), or a page opens yours, the browser can keep a reference between the two windows through the window.opener property. If those two pages come from different origins, that reference becomes a route for a cross-origin page to probe yours.",[16,28,29],{},"The attacks this enables are subtle. They do not steal your data directly; they infer it through side channels, timing, and shared browser state, in a family of techniques the security community calls XS-Leaks. According to Mozilla's documentation, COOP was introduced specifically so a site can ensure its top-level document does not share a browsing context group with cross-origin documents, which is what severs that reference and shuts the route.",[20,31,33],{"id":32},"what-does-the-cross-origin-opener-policy-header-actually-do","What does the Cross-Origin-Opener-Policy header actually do?",[16,35,36],{},"COOP decides whether your document and the pages it interacts with belong to the same browsing context group, which is the internal browser concept that determines whether two windows can script each other. When you set it strictly, your window goes into its own group, and any cross-origin window loses its reference to yours.",[16,38,39],{},"The header has a small set of values. The default, unsafe-none, applies no isolation and lets your document share a browsing context group with cross-origin pages. The strict value, same-origin, isolates your document so only same-origin pages that also set same-origin can stay in the same group. A middle value, same-origin-allow-popups, keeps that isolation but still lets popups you deliberately open function normally, which is the practical choice for sites that rely on popup flows such as payment or single sign-on. When a cross-origin window is opened under same-origin, its window.opener becomes null, so the reference simply does not exist.",[20,41,43],{"id":42},"what-happens-if-you-do-not-set-it","What happens if you do not set it?",[16,45,46],{},"Without COOP the default is unsafe-none, which means no isolation and the window reference stays open. A cross-origin page that opens yours, or that you open, can retain a handle to your window and use it as a foothold for the side-channel techniques described above.",[16,48,49],{},"This is a quiet gap rather than a loud one. Nothing on your site looks broken, and most visitors will never trigger it, which is exactly why it tends to go unaddressed. But for a site that handles anything sensitive, a login, a patient portal, a payment step, leaving the browsing context open is an avoidable exposure, and it is one that security scanners and audits increasingly flag as a missing header.",[20,51,53],{"id":52},"how-do-you-implement-the-cross-origin-opener-policy-header","How do you implement the Cross-Origin-Opener-Policy header?",[16,55,56],{},"You set COOP as a single HTTP response header. For most sites the right starting value is Cross-Origin-Opener-Policy: same-origin-allow-popups, which gives you isolation while preserving popup-based flows; a site with no such dependencies can move to the stricter same-origin. It can be added at the web server, the application layer, or at the edge in a CDN or security layer that sits in front of the site.",[16,58,59],{},"The one strong recommendation is to test before you enforce. COOP supports a report-only mode, sent as Cross-Origin-Opener-Policy-Report-Only, which uses the browser Reporting API to tell you what the policy would break without actually breaking it. Running report-only first, watching for any popup or window flows that would be affected, and only then switching to the enforced header is the safe path, especially on a site with third-party integrations you did not build yourself.",[20,61,63],{"id":62},"what-changes-on-your-site-once-it-is-enabled","What changes on your site once it is enabled?",[16,65,66],{},"For most sites, nothing visible. Ordinary page loads, navigation, and same-origin behaviour are unaffected, and the isolation happens invisibly at the browser level. The change you gain is that cross-origin windows can no longer hold a reference to yours, which removes the attack surface without touching the user experience.",[16,68,69],{},"The place to check is any flow that deliberately opens or is opened by another origin. A payment provider, an identity provider, or an embedded tool that communicates through window references can be affected by a strict same-origin value, which is exactly why same-origin-allow-popups exists and why report-only testing matters. There is also an upside worth knowing: setting same-origin, together with the related Cross-Origin-Embedder-Policy header, puts your document into a cross-origin isolated state that some high-performance browser features require, such as SharedArrayBuffer and high-resolution timers.",[20,71,73],{"id":72},"what-should-you-do-next","What should you do next?",[16,75,76],{},"Start by checking whether your site sends a Cross-Origin-Opener-Policy header at all, since the default of no header means no isolation. If it is absent, the low-risk path is to add it in report-only mode, confirm nothing in your popup or third-party flows breaks, and then enforce same-origin-allow-popups as a sensible default or same-origin if your site has no popup dependencies.",[16,78,79,80],{},"If you would like this checked and configured correctly across your site rather than piecemeal, EuroraCloud can review your current security headers and show you what our platform resolves. ",[81,82,86],"a",{"href":83,"rel":84},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=coop",[85],"nofollow","See what EuroraCloud resolves",[20,88,90],{"id":89},"conclusion-what-should-you-take-away-about-the-cross-origin-opener-policy-header","Conclusion: what should you take away about the Cross-Origin-Opener-Policy header?",[16,92,93],{},"COOP is a quiet but worthwhile header: it isolates your browser window from cross-origin pages, closing a class of side-channel and popup-based attacks that leave no visible sign until a scanner or an attacker finds them. For most sites the safe route is to test in report-only mode, then enforce same-origin-allow-popups, which protects the window while preserving legitimate popup flows. The single most useful step is to check whether your site sends the header today, because until it does, the default is no isolation at all.",{"title":95,"searchDepth":96,"depth":96,"links":97},"",2,[98,99,100,101,102,103,104],{"id":22,"depth":96,"text":23},{"id":32,"depth":96,"text":33},{"id":42,"depth":96,"text":43},{"id":52,"depth":96,"text":53},{"id":62,"depth":96,"text":63},{"id":72,"depth":96,"text":73},{"id":89,"depth":96,"text":90},"Security Headers","2026-07-13","The Cross-Origin-Opener-Policy header lets a page isolate its browser window from cross-origin pages that open it or are opened by it, closing a class of side-channel and popup-based attacks. Here is what it does, how to set it, and what changes when you do.","md",[110,112,114,117,119,122,125],{"question":23,"answer":111},"COOP exists because opening a window creates a scriptable link that can be abused. When one page opens another, the browser can keep a reference between the two windows through window.opener, and if the pages come from different origins that reference becomes a route for a cross-origin page to probe yours through side channels and timing, a family of techniques known as XS-Leaks. COOP lets a site ensure its top-level document does not share a browsing context group with cross-origin documents, which severs that reference.",{"question":33,"answer":113},"COOP decides whether your document and the pages it interacts with belong to the same browsing context group, the internal browser concept that determines whether two windows can script each other. Set strictly, your window goes into its own group and cross-origin windows lose their reference to yours. Values are unsafe-none (the default, no isolation), same-origin (strict isolation), and same-origin-allow-popups (isolation that still allows popups you open). Under same-origin, a cross-origin window's window.opener becomes null.",{"question":115,"answer":116},"What happens if you do not set the Cross-Origin-Opener-Policy header?","Without COOP the default is unsafe-none, meaning no isolation and the window reference stays open. A cross-origin page that opens yours, or that you open, can retain a handle to your window and use it as a foothold for side-channel attacks. Nothing looks broken, which is why it goes unaddressed, but for a site handling a login, patient portal, or payment step it is an avoidable exposure that scanners increasingly flag.",{"question":53,"answer":118},"Set COOP as a single HTTP response header, at the web server, the application layer, or at the edge. For most sites the right starting value is same-origin-allow-popups, which gives isolation while preserving popup flows; a site with no popup dependencies can use the stricter same-origin. Test before enforcing by using the report-only mode, sent as Cross-Origin-Opener-Policy-Report-Only, which reports what the policy would break without breaking it.",{"question":120,"answer":121},"What changes on your site once the Cross-Origin-Opener-Policy header is enabled?","For most sites nothing visible changes; ordinary page loads and same-origin behaviour are unaffected and the isolation happens at the browser level. The place to check is any flow that deliberately opens or is opened by another origin, such as a payment or identity provider, which is why same-origin-allow-popups exists and why report-only testing matters. Setting same-origin together with Cross-Origin-Embedder-Policy also enables a cross-origin isolated state required by some high-performance features like SharedArrayBuffer.",{"question":123,"answer":124},"What should you do next about the Cross-Origin-Opener-Policy header?","Check whether your site sends a Cross-Origin-Opener-Policy header at all, since no header means no isolation. If it is absent, add it in report-only mode, confirm nothing in your popup or third-party flows breaks, and then enforce same-origin-allow-popups as a sensible default, or same-origin if your site has no popup dependencies.",{"question":126,"answer":127},"What should you take away about the Cross-Origin-Opener-Policy header?","COOP is a quiet but worthwhile header that isolates your browser window from cross-origin pages, closing a class of side-channel and popup-based attacks that leave no visible sign. For most sites the safe route is to test in report-only mode, then enforce same-origin-allow-popups, which protects the window while preserving legitimate popup flows. The most useful step is to check whether your site sends the header today, because until it does, the default is no isolation at all.",{},true,"\u002Fblog\u002Fen\u002Fwhat-is-cross-origin-opener-policy","7 minutes",{"title":6,"description":107},"what-is-cross-origin-opener-policy","blog\u002Fen\u002Fwhat-is-cross-origin-opener-policy",[136,105,137,138],"Cross-Origin-Opener-Policy","Web Security","Browser Isolation","Lmp_UM5mDGWoklyUBXXHllY_CBaPGi0GFtpQ5c5p_Ds",{"de":133,"en":133,"es":133,"fr":133,"it":133,"nl":133},[142,255,396],{"id":143,"title":144,"author":7,"body":145,"category":228,"date":106,"description":229,"extension":108,"faq":230,"meta":245,"navigation":129,"path":246,"readingTime":131,"seo":247,"slug":155,"stem":248,"tags":249,"__hash__":254},"blog\u002Fblog\u002Fen\u002Fwhat-is-a-ddos-attack.md","What is a DDoS Attack and How Do You Protect a Website Against One?",{"type":9,"value":146,"toc":220},[147,150,153,157,165,168,172,175,178,181,185,188,191,195,198,201,203,206,213,217],[12,148,144],{"id":149},"what-is-a-ddos-attack-and-how-do-you-protect-a-website-against-one",[16,151,152],{},"A DDoS attack (Distributed Denial of Service) tries to knock a website offline by flooding it with far more traffic than it can handle, sent from many machines at once, until real visitors can no longer get through. Protecting against one means filtering that malicious traffic out before it reaches your server, which is done with a mitigation layer that sits in front of the site and absorbs or blocks the attack. The practical goal is simple: keep the site available for genuine users even while an attack is underway.",[20,154,156],{"id":155},"what-is-a-ddos-attack","What is a DDoS attack?",[16,158,159,160,164],{},"A Denial of Service attack aims to make a website or service unavailable. A ",[161,162,163],"em",{},"Distributed"," Denial of Service attack does the same thing from many sources at once, often thousands of compromised devices acting together as a botnet, which makes it far harder to stop by simply blocking one address. The traffic is designed to exhaust something finite: the server's connections, its processing capacity, or the bandwidth of the network it sits on.",[16,166,167],{},"The key distinction from a normal traffic spike is intent and pattern. A busy sales day sends you more real visitors; a DDoS attack sends you traffic whose only purpose is to consume resources and crowd out those real visitors. According to Cloudflare's DDoS threat reporting, attack volume has risen sharply year on year, and the largest recorded attacks are now measured in the terabits per second, well beyond what any single unprotected server can absorb.",[20,169,171],{"id":170},"how-does-a-ddos-attack-actually-work","How does a DDoS attack actually work?",[16,173,174],{},"Most attacks fall into three broad types, and it helps to know which is which because they are defended differently.",[16,176,177],{},"Volumetric attacks are the brute-force kind: they saturate your available bandwidth with sheer volume, like a UDP flood, so nothing else can get through. Protocol attacks target the way connections are set up, exhausting server or firewall resources with things like SYN floods that open connections and never complete them. Application-layer attacks are the quietest and often the hardest to spot: they mimic real user behaviour, sending requests that look legitimate but are aimed at the most expensive parts of your site, such as a search or login endpoint, until the application buckles.",[16,179,180],{},"What unites all three is that they overwhelm a resource. The defence, in every case, is to identify and remove the malicious traffic before it reaches the resource being targeted.",[20,182,184],{"id":183},"what-does-a-ddos-attack-cost-a-business","What does a DDoS attack cost a business?",[16,186,187],{},"The obvious cost is downtime: while the site is unreachable, visitors cannot book, buy, or contact you, and for a healthcare or clinic site that can mean patients unable to reach care information or appointment forms. Industry estimates commonly put the cost of unplanned web downtime in the thousands of euros per hour for a transacting business, though the real figure depends entirely on what your site does for you.",[16,189,190],{},"The less obvious costs matter too. There is the reputational hit of a site that is visibly down, the staff time pulled into firefighting, and in some cases a DDoS attack used as a smokescreen to distract from a second intrusion attempt. For a regulated or patient-facing organisation, an outage also raises availability and continuity questions that go beyond lost revenue.",[20,192,194],{"id":193},"how-does-ddos-mitigation-keep-a-site-online","How does DDoS mitigation keep a site online?",[16,196,197],{},"Effective mitigation puts a filtering layer between the internet and your server, so traffic is inspected before it ever reaches you. Legitimate visitors pass through; traffic that matches attack patterns is absorbed or dropped at the edge, across distributed infrastructure with far more capacity than a single origin server.",[16,199,200],{},"This works best as an always-on layer rather than something switched on mid-attack, because the first minutes of an attack are when the damage is done. A mitigation service sees the traffic first, recognises the signatures of the attack types above, and scales to absorb volume that would overwhelm your own hardware. At EuroraCloud the DDoS mitigation runs from our decentralised infrastructure across the Netherlands, France, and Germany, which keeps traffic within Europe for data-sovereignty and latency reasons while providing the capacity to absorb large attacks.",[20,202,73],{"id":72},[16,204,205],{},"Start by knowing whether you currently have any mitigation layer at all, since many websites are protected only by their hosting provider's defaults, which are often thin. If an attack today would take your site offline, that is the gap to close, regardless of whether you have ever been hit before, because the point of mitigation is that it is already in place when an attack starts.",[16,207,208,209],{},"If you would like to see where your own site stands, EuroraCloud can review your current setup and show you what our mitigation resolves. ",[81,210,86],{"href":211,"rel":212},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=ddos",[85],[20,214,216],{"id":215},"conclusion-what-should-you-take-away-about-ddos-protection","Conclusion: what should you take away about DDoS protection?",[16,218,219],{},"A DDoS attack does not need to breach anything to hurt you. It simply makes your site unreachable, and for a business that depends on its website to inform, book, or sell, an hour offline is a real cost. The three attack types work differently, but the answer to all of them is the same: a mitigation layer in front of your site that filters malicious traffic before it lands. The single most useful thing you can do is check whether that layer is already in place today, because mitigation only protects you if it is running before an attack begins, not after.",{"title":95,"searchDepth":96,"depth":96,"links":221},[222,223,224,225,226,227],{"id":155,"depth":96,"text":156},{"id":170,"depth":96,"text":171},{"id":183,"depth":96,"text":184},{"id":193,"depth":96,"text":194},{"id":72,"depth":96,"text":73},{"id":215,"depth":96,"text":216},"Fundamentals","A DDoS attack floods your website with traffic until real visitors cannot reach it. Here is how these attacks work, what an outage actually costs, and how mitigation keeps a site online.",[231,233,235,237,239,242],{"question":156,"answer":232},"A DDoS (Distributed Denial of Service) attack tries to make a website unavailable by flooding it with traffic from many sources at once, often thousands of compromised devices acting as a botnet. The traffic is designed to exhaust a finite resource such as the server's connections, its processing capacity, or its network bandwidth, so that real visitors can no longer get through.",{"question":171,"answer":234},"Attacks fall into three broad types. Volumetric attacks saturate available bandwidth with sheer volume. Protocol attacks exhaust server or firewall resources by abusing how connections are set up, such as SYN floods. Application-layer attacks mimic real user behaviour and target expensive endpoints like search or login until the application buckles. All three overwhelm a resource, and the defence in every case is to remove the malicious traffic before it reaches the target.",{"question":184,"answer":236},"The direct cost is downtime: while the site is unreachable, visitors cannot book, buy, or contact you. Estimates commonly put unplanned web downtime in the thousands of euros per hour for a transacting business, though the real figure depends on what the site does. Indirect costs include reputational damage, staff firefighting time, and the risk of a DDoS attack being used as a smokescreen for a second intrusion.",{"question":194,"answer":238},"Mitigation puts a filtering layer between the internet and your server, inspecting traffic before it reaches you. Legitimate visitors pass through while traffic matching attack patterns is absorbed or dropped at the edge, across distributed infrastructure with far more capacity than a single server. It works best as an always-on layer rather than something switched on mid-attack, because the first minutes of an attack are when the damage is done.",{"question":240,"answer":241},"What should you do next to protect a website against DDoS?","Start by checking whether you have any mitigation layer at all, since many sites rely only on their hosting provider's thin defaults. If an attack today would take your site offline, that is the gap to close, regardless of whether you have been hit before, because mitigation only helps if it is already in place when an attack starts.",{"question":243,"answer":244},"What should you take away about DDoS protection?","A DDoS attack does not need to breach anything to hurt you; it simply makes your site unreachable, which is a real cost for any business that depends on its website. The three attack types work differently, but the answer to all of them is a mitigation layer in front of the site that filters malicious traffic before it lands. The most useful thing you can do is check whether that layer is already running today, because mitigation only protects you if it is in place before an attack begins.",{},"\u002Fblog\u002Fen\u002Fwhat-is-a-ddos-attack",{"title":144,"description":229},"blog\u002Fen\u002Fwhat-is-a-ddos-attack",[250,251,252,253],"DDoS","Security","Web Infrastructure","Uptime","ZaAACefTxJdsR-mMmYSjfM9eSoEzUU10L5NeYqnUcgE",{"id":256,"title":257,"author":7,"body":258,"category":105,"date":106,"description":367,"extension":108,"faq":368,"meta":387,"navigation":129,"path":388,"readingTime":131,"seo":389,"slug":390,"stem":391,"tags":392,"__hash__":395},"blog\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy.md","What is the Permissions-Policy Header and Why Does It Matter?",{"type":9,"value":259,"toc":357},[260,263,266,270,273,276,280,293,299,303,306,309,311,314,317,321,324,327,330,332,335,338,340,343,350,354],[12,261,257],{"id":262},"what-is-the-permissions-policy-header-and-why-does-it-matter",[16,264,265],{},"The Permissions-Policy header is a response header that lets a website control which browser features its own pages, and any content embedded in them, are allowed to use. Features like the camera, microphone, geolocation, and payment can each be allowed, restricted to your own origin, or switched off entirely. Setting it means that even if a script or an embedded third party tries to reach one of those features, the browser refuses unless your policy permits it, which reduces both your privacy exposure and your attack surface.",[20,267,269],{"id":268},"why-does-the-permissions-policy-header-exist","Why does the Permissions-Policy header exist?",[16,271,272],{},"Modern browsers expose a lot of powerful capabilities to web pages: location, camera, microphone, motion sensors, and more. Any script running on your page, including third-party scripts you embedded for analytics, chat, or advertising, can in principle ask the browser to use those capabilities. Permissions-Policy exists so you can state, at the level of the whole site, which of those features are allowed and for whom.",[16,274,275],{},"The point is to close the gap between what a browser can do and what your site actually needs. Most websites never use the accelerometer or the payment API, yet without a policy those features remain reachable by any code on the page. According to MDN's documentation, when a policy blocks a feature the user is not even asked for permission, and a script's attempt to use it simply fails, which is exactly the containment you want for features you never intended to use.",[20,277,279],{"id":278},"what-does-the-permissions-policy-header-actually-do","What does the Permissions-Policy header actually do?",[16,281,282,283,287,288,292],{},"The header works as a list of directives, one per feature, each with an allowlist saying which origins may use it. The syntax is the feature name, an equals sign, and the allowed origins in parentheses, with multiple directives separated by commas, for example geolocation=(), camera=(self). An empty allowlist, written as (), disables the feature everywhere; self allows it only on your own origin; a specific origin such as (\"",[81,284,285],{"href":285,"rel":286},"https:\u002F\u002Fexample.com",[85],"\") permits that origin; and ",[289,290,291],"code",{},"*"," allows it everywhere including embedded frames.",[16,294,295,296,298],{},"A useful detail is that each feature has a default allowlist that applies when you say nothing, and depending on the feature that default is one of ",[289,297,291],{},", self, or none. So the value of setting the header explicitly is that you stop relying on per-feature defaults and instead make a deliberate, uniform decision: switch off everything you do not use, and scope everything you do use to your own origin or the specific partners that need it.",[20,300,302],{"id":301},"how-does-the-header-behave-with-embedded-iframes","How does the header behave with embedded iframes?",[16,304,305],{},"This is the part that most often trips people up, so it is worth being precise. A feature is only available inside an embedded iframe if two conditions are both met: your top-level page must allow the feature for that frame's origin in its Permissions-Policy, and the iframe itself must not have disabled it. In other words the parent page sets the outer boundary, and nothing embedded can grant itself a feature the parent has withheld.",[16,307,308],{},"There is also a per-iframe control that works alongside the header, the allow attribute on the iframe element, for example an embedded map added with a frame whose allow attribute permits geolocation. The mental model to keep is that the header is the site-wide policy and the allow attribute is the per-embed exception within it: the frame can only receive what the header already permits, and the attribute then narrows or directs it to that specific embed. This is exactly why a third-party widget sometimes reports that a feature is blocked even though the widget's own code is correct, because the containing page never allowed that feature for the widget's origin in the first place.",[20,310,43],{"id":42},[16,312,313],{},"Without the header, each feature falls back to its own default allowlist, which for several features is more permissive than a typical site needs. In practice that means capabilities you never use remain reachable, and embedded third-party content may be able to request features you would not have granted if you had been asked.",[16,315,316],{},"This is not usually an urgent hole, which is why it goes unaddressed, but it is a real one. It matters most where you embed code you did not write: an analytics tag, a chat widget, a marketing pixel. Restricting features you do not use shrinks what any of that embedded code can attempt, and it is exactly the kind of missing header that security scanners and audits now flag on almost every site that has not set it.",[20,318,320],{"id":319},"how-do-you-implement-the-permissions-policy-header","How do you implement the Permissions-Policy header?",[16,322,323],{},"You set Permissions-Policy as a single HTTP response header. A sensible starting policy is to disable the features you know you do not use and scope the rest to your own origin, for example Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), then loosen individual directives only where a genuine need exists. It can be applied at the web server, the application layer, or at the edge in a CDN or security layer in front of the site.",[16,325,326],{},"It helps to see this against a real site rather than in the abstract. Take a clinic website that shows an embedded map so patients can find the practice, and runs an online booking tool that opens a payment step, but has no other use for browser features. A policy tailored to that site might disable everything it never touches and allow only what those two functions need: geolocation scoped to the map provider's origin, payment scoped to the booking or payment provider, and camera, microphone, and the various sensor features all switched off with an empty allowlist. The result is a page where the map and the checkout work exactly as before, while every other capability is simply unavailable to any script, whether that script is yours or belongs to an embedded third party. The principle generalises: list what the site genuinely uses, allow those to the specific origins that provide them, and close the rest.",[16,328,329],{},"Test before you lock it down. The header has a report-only companion, Permissions-Policy-Report-Only, which uses the browser Reporting API to tell you what a policy would block without actually enforcing it. Running that first is the safe way to discover whether any real feature, a map that needs geolocation, a booking tool that opens a payment flow, an embedded video, would be caught by your policy, so you can allow it deliberately rather than break it by surprise.",[20,331,63],{"id":62},[16,333,334],{},"For most sites, nothing visible. Ordinary pages that do not use restricted features behave exactly as before, and visitors notice nothing, because the policy only intervenes when some code tries to reach a feature you have not allowed.",[16,336,337],{},"The place to check is any feature your own site genuinely relies on, and anything your embedded third parties need. A store locator using geolocation, a video call feature using camera and microphone, or a checkout using the payment API all need their directives set to allow the right origins, which is precisely why report-only testing matters before enforcement. Get that right once and the header quietly holds the line afterwards, allowing what you intended and refusing everything else.",[20,339,73],{"id":72},[16,341,342],{},"Start by checking whether your site sends a Permissions-Policy header at all, since without one every feature simply falls back to its default. If it is absent, the low-risk path is to add it in report-only mode, list the features you actually use, confirm nothing you rely on is being blocked, and then enforce a policy that switches off everything else.",[16,344,345,346],{},"If you would like this reviewed and configured correctly across your whole site rather than piecemeal, EuroraCloud can check your current security headers and show you what our platform resolves. ",[81,347,86],{"href":348,"rel":349},"https:\u002F\u002Fwww.euroracloud.eu\u002F?utm_source=blog&utm_medium=article&utm_campaign=permissions-policy",[85],[20,351,353],{"id":352},"conclusion-what-should-you-take-away-about-the-permissions-policy-header","Conclusion: what should you take away about the Permissions-Policy header?",[16,355,356],{},"Permissions-Policy is a quiet, practical header: it lets you switch off the browser features your site never uses and scope the ones it does to just the origins that need them, so neither your own scripts nor embedded third parties can reach capabilities you never intended to expose. The safe way to adopt it is to test in report-only mode, confirm your real features still work, and then enforce a policy that disables the rest. The single most useful step is to check whether your site sends the header today, because until it does, every feature is left on its default.",{"title":95,"searchDepth":96,"depth":96,"links":358},[359,360,361,362,363,364,365,366],{"id":268,"depth":96,"text":269},{"id":278,"depth":96,"text":279},{"id":301,"depth":96,"text":302},{"id":42,"depth":96,"text":43},{"id":319,"depth":96,"text":320},{"id":62,"depth":96,"text":63},{"id":72,"depth":96,"text":73},{"id":352,"depth":96,"text":353},"The Permissions-Policy header lets a site decide which browser features, like camera, microphone, and geolocation, its own pages and embedded content are allowed to use. Here is what it does, how to set it, and what changes when you do.",[369,371,373,376,378,381,384],{"question":269,"answer":370},"Modern browsers expose powerful capabilities such as location, camera, microphone, and motion sensors, and any script on your page, including embedded third-party code, can in principle ask to use them. Permissions-Policy exists so you can state at the site level which features are allowed and for whom, closing the gap between what a browser can do and what your site actually needs. When a policy blocks a feature the user is not even asked, and a script's attempt to use it simply fails.",{"question":279,"answer":372},"The header is a list of directives, one per feature, each with an allowlist of origins that may use it. The syntax is the feature name, an equals sign, and the allowed origins in parentheses, with directives comma separated, for example geolocation=(), camera=(self). An empty allowlist () disables the feature everywhere, self allows only your own origin, a specific origin permits that origin, and * allows it everywhere. Each feature also has a default allowlist of *, self, or none that applies when you say nothing.",{"question":374,"answer":375},"What happens if you do not set the Permissions-Policy header?","Without the header, each feature falls back to its own default allowlist, which for several features is more permissive than a typical site needs. Capabilities you never use remain reachable, and embedded third-party content may be able to request features you would not have granted. It is rarely urgent, which is why it goes unaddressed, but it matters most where you embed code you did not write, such as an analytics tag, chat widget, or marketing pixel, and scanners now flag it on almost every site that has not set it.",{"question":320,"answer":377},"Set Permissions-Policy as a single HTTP response header, at the web server, the application layer, or the edge. A sensible starting policy disables features you do not use and scopes the rest to your own origin, for example geolocation=(), camera=(), microphone=(), payment=(). Test first with the report-only companion, Permissions-Policy-Report-Only, which uses the browser Reporting API to tell you what a policy would block without enforcing it, so you can allow genuine features deliberately rather than break them by surprise.",{"question":379,"answer":380},"What changes on your site once the Permissions-Policy header is enabled?","For most sites nothing visible changes, because the policy only intervenes when code tries to reach a feature you have not allowed. The place to check is any feature your own site relies on and anything your embedded third parties need, such as a store locator using geolocation, a video feature using camera and microphone, or a checkout using the payment API, all of which need their directives set to allow the right origins. That is why report-only testing matters before enforcement.",{"question":382,"answer":383},"What should you do next about the Permissions-Policy header?","Check whether your site sends a Permissions-Policy header at all, since without one every feature falls back to its default. If it is absent, add it in report-only mode, list the features you actually use, confirm nothing you rely on is blocked, and then enforce a policy that switches off everything else.",{"question":385,"answer":386},"What should you take away about the Permissions-Policy header?","Permissions-Policy lets you switch off the browser features your site never uses and scope the ones it does to just the origins that need them, so neither your own scripts nor embedded third parties can reach capabilities you never intended to expose. The safe way to adopt it is to test in report-only mode, confirm your real features still work, and then enforce a policy that disables the rest. The most useful step is to check whether your site sends the header today, because until it does, every feature is left on its default.",{},"\u002Fblog\u002Fen\u002Fwhat-is-permissions-policy",{"title":257,"description":367},"what-is-permissions-policy","blog\u002Fen\u002Fwhat-is-permissions-policy",[393,105,137,394],"Permissions-Policy","Privacy","ZiEU5nl2sYQEXvib5MFbEOkkO5rKTR5CNWigXFoPvG0",{"id":397,"title":398,"author":7,"body":399,"category":1017,"date":1018,"description":1019,"extension":108,"faq":1017,"meta":1020,"navigation":129,"path":1021,"readingTime":1017,"seo":1022,"slug":1023,"stem":1024,"tags":1025,"__hash__":1028},"blog\u002Fblog\u002Fen\u002Fcore-web-vitals-cdn.md","Core Web Vitals: How a CDN Can Help Your Website Score Better",{"type":9,"value":400,"toc":995},[401,408,411,414,417,421,424,429,436,442,447,463,467,470,476,482,487,501,505,511,517,522,536,540,543,547,552,555,558,563,566,592,597,600,604,607,612,615,620,623,634,637,642,645,656,660,665,668,673,676,690,695,698,702,705,709,714,723,726,731,737,740,744,747,774,778,781,801,805,808,829,833,836,841,852,857,868,871,875,880,883,888,891,896,899,904,907,911,914,919,922,927,941,946,949,954,957,961,964,967,979,981,991],[16,402,403,407],{},[404,405,406],"strong",{},"Keywords:"," Core Web Vitals, CDN performance, LCP optimization, FID improvement, CLS fixes, website speed, Google ranking factors, page experience, web performance optimization, European CDN",[409,410],"hr",{},[16,412,413],{},"In 2021, Google introduced Core Web Vitals as official ranking factors, fundamentally changing how website owners think about performance. These metrics—Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS)—measure real user experience and directly impact your search visibility. As of 2024, Google replaced FID with Interaction to Next Paint (INP), making interactivity even more important.",[16,415,416],{},"If your website struggles with Core Web Vitals, you're not alone. According to recent data, approximately 40% of websites still fail to meet Google's thresholds. The good news? A properly configured Content Delivery Network (CDN) can dramatically improve all three metrics. In this comprehensive guide, we'll explore exactly how.",[20,418,420],{"id":419},"understanding-core-web-vitals-in-2026","Understanding Core Web Vitals in 2026",[16,422,423],{},"Before diving into CDN optimization, let's understand what each metric measures and why it matters.",[425,426,428],"h3",{"id":427},"largest-contentful-paint-lcp","Largest Contentful Paint (LCP)",[16,430,431,432,435],{},"LCP measures loading performance—specifically, how long it takes for the largest visible content element to render. This could be a hero image, a video thumbnail, or a large block of text. Google considers a good LCP to be ",[404,433,434],{},"2.5 seconds or less",".",[16,437,438,441],{},[404,439,440],{},"Why LCP matters:"," Users perceive a page as \"loaded\" when they can see the main content. A slow LCP means visitors stare at a blank or partially loaded screen, increasing bounce rates.",[16,443,444],{},[404,445,446],{},"Common LCP problems:",[448,449,450,454,457,460],"ul",{},[451,452,453],"li",{},"Slow server response times",[451,455,456],{},"Render-blocking JavaScript and CSS",[451,458,459],{},"Large, unoptimized images",[451,461,462],{},"Client-side rendering delays",[425,464,466],{"id":465},"interaction-to-next-paint-inp","Interaction to Next Paint (INP)",[16,468,469],{},"INP replaced First Input Delay in March 2024 and measures overall responsiveness throughout the entire page lifecycle. While FID only measured the delay of the first interaction, INP considers all interactions—clicks, taps, and keyboard inputs—and reports the worst one (with some statistical smoothing).",[16,471,472,473,435],{},"Google considers a good INP to be ",[404,474,475],{},"200 milliseconds or less",[16,477,478,481],{},[404,479,480],{},"Why INP matters:"," Users expect immediate feedback when they interact with your website. A laggy button or unresponsive form feels broken, even if the page loaded quickly.",[16,483,484],{},[404,485,486],{},"Common INP problems:",[448,488,489,492,495,498],{},[451,490,491],{},"Heavy JavaScript execution blocking the main thread",[451,493,494],{},"Third-party scripts competing for resources",[451,496,497],{},"Inefficient event handlers",[451,499,500],{},"Complex DOM operations during interactions",[425,502,504],{"id":503},"cumulative-layout-shift-cls","Cumulative Layout Shift (CLS)",[16,506,507,508,435],{},"CLS measures visual stability—how much the page content moves around during loading. Every time an element shifts position unexpectedly, it contributes to your CLS score. Google considers a good CLS to be ",[404,509,510],{},"0.1 or less",[16,512,513,516],{},[404,514,515],{},"Why CLS matters:"," Unexpected layout shifts are infuriating. You're about to click a link, and suddenly an ad loads above it, pushing everything down. Now you've clicked the wrong thing. CLS captures this frustration quantitatively.",[16,518,519],{},[404,520,521],{},"Common CLS problems:",[448,523,524,527,530,533],{},[451,525,526],{},"Images and embeds without defined dimensions",[451,528,529],{},"Dynamically injected content",[451,531,532],{},"Web fonts causing text reflow",[451,534,535],{},"Ads and iframes loading late",[20,537,539],{"id":538},"how-a-cdn-improves-each-core-web-vital","How a CDN Improves Each Core Web Vital",[16,541,542],{},"A CDN isn't just about speed—it's a performance multiplier that addresses multiple pain points simultaneously. Here's how it helps each metric.",[425,544,546],{"id":545},"cdn-impact-on-lcp","CDN Impact on LCP",[16,548,549],{},[404,550,551],{},"Reduced Time to First Byte (TTFB)",[16,553,554],{},"The single biggest factor in LCP is often TTFB—how long the browser waits before receiving the first byte of HTML. When your server is in Frankfurt and your visitor is in Madrid, every request must travel hundreds of kilometers. A CDN with edge servers across Europe eliminates this latency.",[16,556,557],{},"With EuroraCloud's 45+ European points of presence, your content is served from a location typically within 50ms of your visitors. This alone can shave 200-500ms off your LCP.",[16,559,560],{},[404,561,562],{},"Optimized Image Delivery",[16,564,565],{},"Images are the LCP element on most pages. A CDN can:",[448,567,568,574,580,586],{},[451,569,570,573],{},[404,571,572],{},"Serve modern formats:"," Automatically convert images to WebP or AVIF, reducing file sizes by 30-50%",[451,575,576,579],{},[404,577,578],{},"Responsive sizing:"," Deliver appropriately sized images based on device viewport",[451,581,582,585],{},[404,583,584],{},"Lazy loading optimization:"," Ensure above-the-fold images load immediately while deferring others",[451,587,588,591],{},[404,589,590],{},"Compression:"," Apply optimal compression without visible quality loss",[16,593,594],{},[404,595,596],{},"Caching eliminates origin requests",[16,598,599],{},"When content is cached at the edge, visitors receive it directly without any request to your origin server. This is dramatically faster than even the most optimized origin response.",[425,601,603],{"id":602},"cdn-impact-on-inp","CDN Impact on INP",[16,605,606],{},"While INP is primarily influenced by client-side JavaScript, a CDN contributes in several important ways:",[16,608,609],{},[404,610,611],{},"Faster script delivery",[16,613,614],{},"Your JavaScript files reach visitors faster when served from edge locations. This means your interactive elements become functional sooner.",[16,616,617],{},[404,618,619],{},"HTTP\u002F3 and connection optimization",[16,621,622],{},"Modern CDNs support HTTP\u002F3 (QUIC), which provides:",[448,624,625,628,631],{},[451,626,627],{},"Zero round-trip connection establishment",[451,629,630],{},"Improved packet loss recovery",[451,632,633],{},"Multiplexed streams without head-of-line blocking",[16,635,636],{},"These optimizations reduce the overhead of loading multiple resources, leaving more main thread time for handling interactions.",[16,638,639],{},[404,640,641],{},"Edge computing for dynamic features",[16,643,644],{},"Advanced CDNs offer edge computing capabilities, allowing you to run logic at the network edge. This can offload work from the client:",[448,646,647,650,653],{},[451,648,649],{},"A\u002FB testing decisions at the edge instead of client-side",[451,651,652],{},"Personalization without JavaScript",[451,654,655],{},"Form validation and processing",[425,657,659],{"id":658},"cdn-impact-on-cls","CDN Impact on CLS",[16,661,662],{},[404,663,664],{},"Placeholder and dimension enforcement",[16,666,667],{},"A CDN with image optimization can automatically add width and height attributes to images, preventing layout shifts as they load.",[16,669,670],{},[404,671,672],{},"Font optimization",[16,674,675],{},"Web fonts are a major CLS culprit. When a custom font loads, it often causes text to reflow (known as FOUT—Flash of Unstyled Text). CDN optimization includes:",[448,677,678,681,684,687],{},[451,679,680],{},"Preloading critical fonts",[451,682,683],{},"Font subsetting to reduce file sizes",[451,685,686],{},"font-display: swap handling",[451,688,689],{},"Serving fonts from edge locations for faster loading",[16,691,692],{},[404,693,694],{},"Consistent third-party loading",[16,696,697],{},"While you can't control how third-party scripts behave, serving them through your CDN (when possible) provides more consistent timing, reducing unexpected shifts.",[20,699,701],{"id":700},"practical-cdn-configuration-for-core-web-vitals","Practical CDN Configuration for Core Web Vitals",[16,703,704],{},"Let's get specific about how to configure your CDN for optimal Core Web Vitals.",[425,706,708],{"id":707},"caching-strategy","Caching Strategy",[16,710,711],{},[404,712,713],{},"Static assets (images, CSS, JS):",[715,716,721],"pre",{"className":717,"code":719,"language":720},[718],"language-text","Cache-Control: public, max-age=31536000, immutable\n","text",[289,722,719],{"__ignoreMap":95},[16,724,725],{},"Use long cache durations with cache-busting filenames for versioning.",[16,727,728],{},[404,729,730],{},"HTML documents:",[715,732,735],{"className":733,"code":734,"language":720},[718],"Cache-Control: public, max-age=300, stale-while-revalidate=86400\n",[289,736,734],{"__ignoreMap":95},[16,738,739],{},"Short TTL with stale-while-revalidate ensures fresh content while avoiding origin delays.",[425,741,743],{"id":742},"image-optimization-settings","Image Optimization Settings",[16,745,746],{},"Enable these features if your CDN supports them:",[748,749,750,756,762,768],"ol",{},[451,751,752,755],{},[404,753,754],{},"Automatic WebP\u002FAVIF conversion"," - Serve modern formats to supported browsers",[451,757,758,761],{},[404,759,760],{},"Responsive images"," - Deliver appropriate sizes via Client Hints",[451,763,764,767],{},[404,765,766],{},"Lazy loading injection"," - Add loading=\"lazy\" to below-fold images",[451,769,770,773],{},[404,771,772],{},"Quality optimization"," - Use perceptual quality metrics (like SSIM) rather than fixed compression",[425,775,777],{"id":776},"preloading-critical-resources","Preloading Critical Resources",[16,779,780],{},"Use HTTP\u002F2 Server Push or 103 Early Hints to preload critical resources:",[715,782,786],{"className":783,"code":784,"language":785,"meta":95,"style":95},"language-http shiki shiki-themes github-light github-dark","Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\nLink: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n","http",[289,787,788,796],{"__ignoreMap":95},[789,790,793],"span",{"class":791,"line":792},"line",1,[789,794,795],{},"Link: \u003C\u002Ffonts\u002Fmain.woff2>; rel=preload; as=font; crossorigin\n",[789,797,798],{"class":791,"line":96},[789,799,800],{},"Link: \u003C\u002Fcss\u002Fcritical.css>; rel=preload; as=style\n",[425,802,804],{"id":803},"security-headers-without-performance-cost","Security Headers Without Performance Cost",[16,806,807],{},"CDNs can add security headers at the edge without impacting your origin:",[715,809,811],{"className":783,"code":810,"language":785,"meta":95,"style":95},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\nX-Content-Type-Options: nosniff\nReferrer-Policy: strict-origin-when-cross-origin\n",[289,812,813,818,823],{"__ignoreMap":95},[789,814,815],{"class":791,"line":792},[789,816,817],{},"Content-Security-Policy: default-src 'self'; img-src 'self' data: https:;\n",[789,819,820],{"class":791,"line":96},[789,821,822],{},"X-Content-Type-Options: nosniff\n",[789,824,826],{"class":791,"line":825},3,[789,827,828],{},"Referrer-Policy: strict-origin-when-cross-origin\n",[20,830,832],{"id":831},"measuring-the-impact","Measuring the Impact",[16,834,835],{},"After implementing CDN optimizations, measure your improvements using:",[16,837,838],{},[404,839,840],{},"Lab tools (synthetic testing):",[448,842,843,846,849],{},[451,844,845],{},"Google Lighthouse",[451,847,848],{},"WebPageTest",[451,850,851],{},"Chrome DevTools Performance panel",[16,853,854],{},[404,855,856],{},"Field data (real users):",[448,858,859,862,865],{},[451,860,861],{},"Google Search Console Core Web Vitals report",[451,863,864],{},"Chrome User Experience Report (CrUX)",[451,866,867],{},"Real User Monitoring (RUM) solutions",[16,869,870],{},"The CrUX data is what Google actually uses for ranking, so prioritize field data over lab measurements.",[20,872,874],{"id":873},"common-mistakes-to-avoid","Common Mistakes to Avoid",[16,876,877],{},[404,878,879],{},"Over-caching dynamic content",[16,881,882],{},"Caching HTML too aggressively can cause users to see stale content. Use appropriate TTLs and cache-busting for personalized elements.",[16,884,885],{},[404,886,887],{},"Ignoring mobile users",[16,889,890],{},"Mobile networks have higher latency and more variable performance. Test specifically on throttled mobile connections.",[16,892,893],{},[404,894,895],{},"Forgetting about third parties",[16,897,898],{},"Your CDN can only optimize resources it serves. Audit third-party scripts and remove or defer non-essential ones.",[16,900,901],{},[404,902,903],{},"Measuring only lab data",[16,905,906],{},"Lab tests show potential, not reality. Your real users might have different devices, networks, and behaviors.",[20,908,910],{"id":909},"why-european-businesses-choose-euroracloud","Why European Businesses Choose EuroraCloud",[16,912,913],{},"For European websites, data locality matters—both for compliance and performance. EuroraCloud offers:",[16,915,916],{},[404,917,918],{},"45+ European Edge Locations",[16,920,921],{},"From Lisbon to Helsinki, Stockholm to Athens, your content is cached close to your European visitors. This translates to consistently fast LCP times across the continent.",[16,923,924],{},[404,925,926],{},"Built-in Performance Features",[448,928,929,932,935,938],{},[451,930,931],{},"Automatic image optimization with WebP\u002FAVIF support",[451,933,934],{},"HTTP\u002F3 enabled by default",[451,936,937],{},"Smart caching with instant purge capability",[451,939,940],{},"Real-time performance analytics",[16,942,943],{},[404,944,945],{},"GDPR-Compliant Infrastructure",[16,947,948],{},"All processing happens within the EU. No data transfers to third countries, simplifying your compliance obligations.",[16,950,951],{},[404,952,953],{},"Simple, Transparent Pricing",[16,955,956],{},"No hidden fees for features that should be standard. Performance optimization is included, not an add-on.",[20,958,960],{"id":959},"conclusion","Conclusion",[16,962,963],{},"Core Web Vitals aren't just vanity metrics—they directly impact your search rankings and user experience. A CDN is one of the most effective tools for improving all three metrics simultaneously.",[16,965,966],{},"By reducing latency, optimizing assets, and providing modern delivery protocols, a properly configured CDN can transform your Core Web Vitals scores. For European businesses, choosing a CDN with strong European presence ensures the best possible experience for your primary audience.",[16,968,969,972,973,978],{},[404,970,971],{},"Ready to improve your Core Web Vitals?"," ",[81,974,977],{"href":975,"rel":976},"https:\u002F\u002Fwww.euroracloud.eu",[85],"Try EuroraCloud free for 14 days"," and see the difference a European-first CDN can make.",[409,980],{},[16,982,983],{},[161,984,985,986,990],{},"Have questions about optimizing your Core Web Vitals? Contact our performance team at ",[81,987,989],{"href":988},"mailto:support@euroracloud.eu","support@euroracloud.eu"," - we're happy to help.",[992,993,994],"style",{},"html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":95,"searchDepth":96,"depth":96,"links":996},[997,1002,1007,1013,1014,1015,1016],{"id":419,"depth":96,"text":420,"children":998},[999,1000,1001],{"id":427,"depth":825,"text":428},{"id":465,"depth":825,"text":466},{"id":503,"depth":825,"text":504},{"id":538,"depth":96,"text":539,"children":1003},[1004,1005,1006],{"id":545,"depth":825,"text":546},{"id":602,"depth":825,"text":603},{"id":658,"depth":825,"text":659},{"id":700,"depth":96,"text":701,"children":1008},[1009,1010,1011,1012],{"id":707,"depth":825,"text":708},{"id":742,"depth":825,"text":743},{"id":776,"depth":825,"text":777},{"id":803,"depth":825,"text":804},{"id":831,"depth":96,"text":832},{"id":873,"depth":96,"text":874},{"id":909,"depth":96,"text":910},{"id":959,"depth":96,"text":960},null,"2026-02-09","Published: February 9, 2026 | Category: Performance | Reading time: 8 minutes",{},"\u002Fblog\u002Fen\u002Fcore-web-vitals-cdn",{"title":398,"description":1019},"core-web-vitals-cdn","blog\u002Fen\u002Fcore-web-vitals-cdn",[1026,1027,137],"CDN","Performance","t7EAfJSEyvKVo2lmIph9IGui8Zd6BVFetJs6hwFPcWc",1785141119656]