ERR_BLOCKED_BY_CLIENT and HTML5 Sandbox

Recently, many Microsoft employees taking training courses have reported problems accessing documents linked to in those courses in Chrome and Edge.

In Edge, the screen looks like this:

But the problem isn’t limited to Microsoft’s internal training platform, and can be easily reproduced in Chrome:

What’s going on?

There are a number of root causes for an ERR_BLOCKED_BY_CLIENT message, and the most common root cause is that you’ve installed a content-blocking extension (e.g. an ad-blocker) and it directed the browser to block the page.

But that’s not what’s happening here — we saw this on machines without any content blocking extensions.

What’s happening here is that the PDF viewer is blocked from loading because the new tab was created as a popup under the restrictions of the HTML5 Sandbox. The sandbox rules applied to the new tab include prohibitions on script and extensions, and Chromium’s PDF viewer requires both. So, the user ends up with a totally inexplicable blocking page.

Refreshing the page will not fix it, and shockingly, even navigating the tab to a different, non-PDF URL, will still likely result in failures (either script won’t run, or the page will not load) because the sandboxing limits are not removed upon manual navigation. For instance, Twitter refuses to load:

Twitter shows ERR_BLOCKED_BY_RESPONSE due to its use of Cross-Origin-Opener-Policy

As an end-user, the workaround is easy: Copy/paste the URL from the broken tab to a new one and your document will load just fine.

As a web developer, to avoid creating unexpectedly impaired tabs, you must set the allow-popups-to-escape-sandbox flag; when you do so, new windows will not be restricted.

A quick look showed that our company training app specifies this flag, but the new tab was still impaired.

What gives?

A deeper look showed that the training app contains nested sandboxes — while an inner iframe includes the allow token, that iframe’s parent does not have the token.

The grandparent’s restriction on its child also restricts its grandchild:

Perhaps the Chromium dev tools should warn if a child iframe‘s sandbox directive specifies permissions that that will be denied by the grandparent’s restrictions on the parent?

Mouse Gestures in Edge

Over twenty years ago, the Opera browser got me hooked on mouse gestures, a way for you to perform common browser actions quickly. After I joined the IE team in 2004, I fell in love with a browser extension written by Ralph Hare and I later blogged about it on the IEBlog and helped Ralph get it running in 64bit IE.

Many years passed. By 2015, I had abandoned the outdated IE and moved to Chrome fulltime. When I joined the Chrome team in 2016, I was heartened to note that mouse gestures were one of the very few features slated for inclusion in the first version of Chrome. They were repeatedly postponed and eventually cut, with the idea that perhaps a browser extension was the way to go. I installed the most popular Mouse Gestures extension from the Chrome web store only to later discover that it was sending my browser traffic to a questionable server in China. I uninstalled it and reported it to the Chrome Web Store folks who delisted it. Apparently a while later they slightly reduced the data leakage and got it back up on the Web Store, and in 2019 a new hire PM lead on the Edge team suggested we all install it. I took a look at what it was doing and found that it was still engaged in questionable privacy practices. Bummer.

Fast forward to earlier this year, when I discovered that the Edge team has landed gestures in Edge on Windows! I was excited to see the implementation, and feel like it’s one of several features that makes Edge feel like it’s a batteries-included browser. (Unfortunately, this feature presently seems to be Windows-only. If you’re using a Mac or Linux, you should click the menu … >Help and Feedback > Send Feedback to ask for it.)

Dozens (hundreds?) of times a day, I enjoy the satisfaction of closing browser tabs by right-click-drawing a “L” on them.

To enable Mouse Gestures support in Edge, simply visit edge://flags/#edge-mouse-gesture and enable the feature:

After you restart the browser you can go visit the edge://settings/mouseGesture page to configure them:

Don’t worry about memorizing a ton of shortcuts — I really only use two: back (right-click+left-drag) and close tab (right-click+DrawL).

I smile every time this works, and every time I test something in Chrome I lament their absence.

-Eric

PS: Besides support for Mac OS, one other missing feature I’d love to see is the ability to bind a gesture to an extension or JavaScript-bookmarklet. That would allow me to recreate one of my other IE-era gestures– I could waggle my mouse to run a JavaScript which would remove all ad-like elements from a page.

Going Electric – Solar 1 Year Later

In March of 2023, I had an 8kw solar array installed and I was finally permitted to turn it on starting April 21, 2023.

My pessimistic/optimistic assumption that my buying an expensive solar array was going to be the trigger for technological breakthroughs in solar technology that rendered my panels obsolete wasn’t entirely unfounded. Sure enough, shortly after the install, I started hearing more and more about promising next-generation ‘tandem’ solar cells that will deliver even more power. You’re welcome. Still, those new cells are probably still at least a few years away from broad production, and staying out of the market for another decade didn’t feel like the right choice for me.

The summer of 2023 was a hot one, but my panels achieved one major goal I had in buying them — I stopped cursing the sun on clear summer days.

But how’d I do against the sales pitch from the installer?

Well, not great. The solar installer estimated that I would produce 11.27MWh in my first year. I came in a bit lower than that, producing 10.7MWh, a 5% shortfall. While I never expected the nominally 400W panels to produce at their max for much of the day, they’ve never hit anything close to that (my “8KW” array peaks at 6.4KW).

In the first year, the best panel outperformed the worst by 10%.

I also consumed almost 3MWh (38%) more than expected for the year. Of that excess, my Nissan Leaf explains about half (1.5MWh) for the 6700 miles I’ve driven since I installed the panels.

It looks like peak daily production was 48.4KWh on my 9th day of ownership, although I was hitting 40KWh/day for most of the summer. While Austin’s scorching summer days make the panels less efficient, the longer daylight hours and fewer clouds meant that I hit 1.2MWh/month for July and August.

Over the summer months, you can see the big deficit as the air-conditioner works overtime, but over the winter and spring you can see the solar production outpacing consumption (heating is via natural gas):

My lowest consumption day of the year was 6.1KWh (no one was home).

The most fun part of the system is getting negative bills for electricity:

My panels saved me about $1060 ($.0991/KWh) in the first year, making for a pretty long payback period. I’d initially expected the system, post-credits and deductions, to cost $15000, but it turns out that you have to deduct your utility incentives from the cost against which you’re getting a Federal tax credit, so my $2500 Austin Energy incentive reduced my federal credit down from $7470 to a still-respectable $6720.

So, after credits, my Final Installation Cost was $15,680, leaving a payback period of 15 years. Not awesome, but again, the major goal I had in buying solar was that I stopped cursing the sun on clear summer days.

The Enphase monitoring site says that my 10.7MW/h production has saved 7.6 Tons of CO2, or 128 trees.

Thoughts On Batteries 🔋

When I installed my system, I opted not to buy the battery backup system for the house despite the fact that it meant I’d miss out on the federal tax credit available only when solar is first installed. I reasoned that the battery system would itself cost $1000 per year, and in ten years in Austin I have only lost power for a few days. Besides, battery technology is widely expected to continue to improve with every passing year, and hopefully soon using electric cars’ batteries as home backup will become commonplace (even my Leaf’s tiny battery is 40KWh, twice the capacity of a large home system).

Shortly after that decision to forgo the battery, we had our longest-ever power outage, 56 hours, and I wondered whether I’d made a mistake. Ah well.

Before the winter storms of 2024, I bought a 768Wh power station for $475 and predictably (given my luck) the power company managed to keep the power on throughout this year’s storms.

What’s Next? ⚡️

I’d heard great things about induction cooking, so I decided to dip my toes in with a portable cooktop. I like it a lot — it’s convenient and super-fast for boiling water for HelloFresh meals. I’d like to replace my entire stove, but I will likely need an electrical panel upgrade to do that, since my current panel is already at capacity with the car charger.

In the next few years, I’d like to get rid of natural gas entirely (my monthly bill is $26 even if I don’t use any gas). My water heater will age out first and I’ll likely replace it with a hybrid. The big lift will be replacing the heating and air conditioning with a heat pump — bizarrely, these are not yet common in Texas, but they make a lot of sense in this climate and the new federal incentives should help reduce the costs somewhat.


June 2024 Update

My system stopped reporting its power production to the Internet portal on May 7th, 2024. My support ticket with Native Solar got no response for a few weeks, and my DIY attempt to manually reset the Enphase gateway didn’t help. Fortunately, from the credit on my power bill, it looks like the panels are still producing as expected. A month after the outage began, I nagged them again and Native Solar told me that for a $300 fee they’ll come out and troubleshoot the system for up to an hour, something I would’ve assumed would be covered under the warranty. Suffice it to say, I don’t have a very good opinion of Native Solar any longer. :-( After a few easy email exchanges, Enphase sent me a new WiFi connector module, and on August 15th I finally had Native Solar come out to install it. Next, I find out whether Enphase’s reimbursement program will reimburse me for the installation.

Browser Security Bugs that Aren’t: JavaScript in PDF

A fairly common security bug report is of the form: “I can put JavaScript inside a PDF file and it runs!

For example, open this PDF file with Chrome, and you can see the alert(1) message displayed:

Support for JavaScript within PDFs is by-design and expected by the developers of PDF rendering software, including common browsers like Chrome and Edge. Much like HTML, PDF files are an active content type and may contain JavaScript.

Periodically, less experienced security researchers excitedly file this issue against browsers, and those reports are quickly resolved “By Design.”

Periodically, more experienced security researchers excitedly file this issue against sites and applications that are willing to host or transfer untrusted PDF files, arguing that this represents a “Stored Cross-Site Scripting vulnerability.”

Their confusion here is somewhat more understandable– if a website allows a user to upload a HTML document containing script, and then serves that HTML document from their domain, any script within it will run in the security context of the serving domain. That describes a classic Stored XSS Attack, and it presents a security threat because the embedded script can steal or manipulate cookies (by accessing the document.cookie property), manipulate web platform storage (IndexedDB, localStorage, etc), conduct request forgery attacks from a 1st party origin, etc.

The story for PDF documents is very different.

The Chrome Security FAQ describes the limitation tersely, noting the set of bindings provided to the PDF are more limited than those provided by the DOM to HTML documents, nor do PDFs get any ambient authority based upon the domain from which they are served.

What does that mean? It means that, while PDF’s JavaScript does run, the universe the script runs in is limited: there’s no access to cookies or storage, very limited ability to make requests (e.g. you can navigate the document’s window elsewhere after a user gesture, but that’s about it), and no ability to make use of the Web Platform’s powerful capabilities exposed by the HTML Document Object Model (DOM) objects like document, window, navigator, et cetera. While the capabilities of JavaScript in PDF are extremely limited, they’re not non-existent, and PDF engine software must take care to avoid introducing new capabilities that void the safety assumptions of PDF-handling code.

Restricting JavaScript in PDF

Engineers should take care that handling of JavaScript in PDF respects app/user settings. For example, if the user turns off JavaScript for a site, PDFs hosted on that site shouldn’t allow script either. This works properly in Chrome and Edge.

Firefox’s global javascript.enabled toggle from the about:config page doesn’t impact script inside its PDF viewer:

Instead, Firefox offers an individual pdfjs.enableScripting preference that can be configured from the about:config page.

Chromium currently ignores Content-Security-Policy headers on PDF responses because it renders PDF files using web technologies that could otherwise be disallowed by the CSP, leading to user confusion and webdev annoyance.

A Slow 10K

I “ran” the Capitol 10K for a third time on Sunday. It did not go well, but not for any of the reasons I worried about. The rain stopped hours before the race, and the course wasn’t wet. My knees and feet didn’t complain. My heart rate felt pretty much under control. I had found the charger for my running watch and got my headphones charged.

No, like my first race, I got screwed by nutrition. After mile 2, I was feeling heartburn for the first time in months (years?), and I began frequently dropping to a walk while I worried about it. Was it the flavored coffee I had in the morning? My dubious dinner (Subway) or the beer I had with it? In hindsight, the real problem was probably some red wine I’d had the prior afternoon — I don’t drink wine often anymore, and I’m more sensitive to it. Ah well, whatever the cause, you can see the impact.

You can see where things went off the rails. My first half was a non-disastrous 4 minutes slower than last year, but my second half took my 6 minutes longer than the first. The only bright spot was the short uphill “King of the hill” segment, which I completed at a pace of 8:15/mi vs. last year’s 9:32/mi. (Update: I misread this, and actually took much longer on the KQ Hill than last year, but further research strongly suggests that they pick a different length/hill each race).

I spent miles 3 to 5 mostly walking through the neighborhoods that I’d joyfully sped through last year, watching my fellow “A” group people blow by, wondering if I was ever going to be able to run a half marathon again after this puny 10k was killing me.

By mile 5, I was starting to feel somewhat better but I still held off on picking up the pace, recognizing that this was not going to be my day. Unlike last year, I didn’t hear my (phantom) children cheering as I turned the final corner after the bridge and sped up for the finish line.

I finished in 1:06:15, a pokey 10:40/mi pace, 14 minutes slower than last year, 8.5 minutes slower than my fall Daisy Dash, and just 83 seconds faster than my first Cap10K. Not a great result.

I’ve signed up for the Sunshine 10K next month to hopefully find myself back on track, and also got the early-bird discount for signing up for the 2025 Cap10K.

Better luck prep next time?

-Eric

PS: Bonus pic from yesterday’s (cloudy) total eclipse in Austin.