LWN: Comments on "Design for security"

Design for security

excors — Sat, 23 Feb 2019 23:59:24 +0000

> BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.

The "Recents" screen shows activities and tasks (which I think correspond to certain Java objects), not apps or processes. When the user closes something from that list, I think it does destroy the activity if it's still alive, per https://developer.android.com/guide/components/activities..., so it's doing more than just hiding it from the list. But it still probably won't terminate the process if that was its last activity - it just increases the likelihood of it being chosen by the Low Memory Killer when someone else wants the memory.

Conversely, an activity can remain in the Recents list after its process has been terminated by the LMK. A new process can be started and told to resume that activity. So there's little correlation between process lifetime and activity visibility.

Design for security

jezuch — Sat, 23 Feb 2019 17:34:16 +0000

In addition to what others said...

How do you guarantee that the gateways do not cheat and are not sending data unencrypted? How do you verify this? It's like today's email: how do I know that my mail provider is not broadcasting my poorly written and utterly embarrassing (but really sweet to the addressee) love letters to other mail exchanges as plain text? (An obvious response to an obvious retort: mail encryption is rubbish and my girlfriend refuses to use it.)

BTW, you may be confused that when you "close" an app it is in fact closed. More likely it is just removed from the list of recent apps, unless you're going to the settings > applications > particular app > stop process > yes, I really want to kill it and I know it may break the app. It gets tiresome really quick.

Design for security

mpr22 — Fri, 22 Feb 2019 19:36:50 +0000

One does not have to believe oneself to be a Designated Undesirable to prefer that one's internet traffic be end-to-end encrypted rather than per-hop encrypted.

My ISP's gateway, my bank's ISP's gateway, and the six other gateways between my ISP's gateway and my bank's ISP's gateway have no business being able to know my access credentials for my bank's online services.

Design for security

nix — Fri, 22 Feb 2019 15:22:21 +0000

I haven't addressed buffer bloat.

These days, for wired Ethernet at least, just switching to fq_codel or CAKE on your bottleneck link with the default parameters (or default plus telling it what your ADSL encapsulation etc is) should be enough to fix that, as long as your NIC driver supports BQL, which most now do.

Design for security

nix — Fri, 22 Feb 2019 15:16:02 +0000

The proper solution is host-to-gateway and gateway-to-gateway opportunistic encryption. Prevent deliberate, casual or incidental observation of private/confidential data, but allow perimeter firewalls to block trojans, viruses, ransomware, phishing, data theft, and other 'crimes'. (People who are terrified that someone might see what they're doing on an internetwork probably shouldn't be using the net in the first place. IMO.)

And what do you do when you work, as I used to, for a megacorp with a centralized, out-of-touch, uncontactable security department that listens mostly to expensive consultants and flatly refuses to allow things that entire national divisions need to do their jobs? Just sit there all day and do no work?

People bypass security when it impedes them. Otherwise, they mostly ignore it. You can't get rid of that by saying "but nothing should be encrypted except via gateways operated by the Right People": if the Right People are idiots, this will not help, and it makes the gateways into a huge target that attackers will naturally penetrate, and now they have everything so you are paying the cost of security for nothing.

Many smart phones have multi-GiB RAM because people don't know or don't care that they have 500 apps open. When I finish using an app on my phone, I close it; I think the most apps I ever had open at one time was 8.

This seems utterly bizarre to me. I just leave things open and let the phone transparently close things in the background when memory is short. Usually the only visible effect of this is having to go back in via the home screen, and a slight delay on switching back as the app reloads its state. Why do you care if the app is being persisted in normal use, any more than you care which pages are in the page cache in normal use? Why on earth would you try to kick things out, unless you like making your own life harder?

Design for security

fest3er — Thu, 21 Feb 2019 03:41:59 +0000

The real problem can be illustrated by a quote from the movie, Cool Hand Luke: "What we've got here is failure to communicate." After 40 years in the field, I *still* find evidence of far too many software professionals who either can't or won't clearly communicate their thoughts to other people.

It gets down to the most fundamental characteristic of inter-human communication: the fact that *all* human languages are programming languages because human language is the effort of one person to program others' neural nets to think her thoughts. Some day I'll challenge all software people to master English (or at least master their native languages). The internet is rife with examples of ambiguous human programs. Shoot, a reading of NHRA's carefully-prepared rule book will reveal lots of ambiguities; some rule is intended to prevent injury A, so the racer must do Q but the rule, as written, allows lesser X, Y, and Z actions as well. (As much as I try to write clear English, I often still fail to communicate my thoughts to others; I'm sure this missive will be no exception.)

The BeyondCorp security model was mentioned, in that it opened one's private internetwork to the universe. Something that isn't quite as bad is TLS because it bypasses the private internetwork's perimeter firewall. Once the encrypted link it established, the firewall cannot block malware or theft. IMO, the time of SSL/TLS is long past and it should be largely retired; the recent push to shove TLS everywhere is misguided at best. The proper solution is host-to-gateway and gateway-to-gateway opportunistic encryption. Prevent deliberate, casual or incidental observation of private/confidential data, but allow perimeter firewalls to block trojans, viruses, ransomware, phishing, data theft, and other 'crimes'. (People who are terrified that someone might see what they're doing on an internetwork probably shouldn't be using the net in the first place. IMO.) VPNs must be allowed, but all network traffic other than the VPN should be forced through the business/SOHO/personal firewall so that it can be filtered and inspected for malware. Most people don't use VPNs because most software engineers and programmers make it too hard to use.

Basically, I generally agree with Miss Chen. Usability and security must go hand-in-hand. Engineers, programmers and coders nede to learn to think like ordinary people; they need to crawl out of their virtual universes and learn to communicate with non-technical people. And non-technical people need to learn some of the tech terminology so they can more readily learn how to best use the tech they own. Many smart phones have multi-GiB RAM because people don't know or don't care that they have 500 apps open. When I finish using an app on my phone, I close it; I think the most apps I ever had open at one time was 8. When I need the net, I turn WiFi or cell data on. When done, I turn them off.

Design for security

fest3er — Thu, 21 Feb 2019 02:50:33 +0000

No need to buy anything. Get a late-model PC (dual-core, 1.6GHz CPU or faster, 2GiB RAM, SATA HD, and 2-4 NICs depending on how many zones you want), and install Smoothwall Express on it. I spent a good amount of time getting its QoS (Traffic Control) to work well. Since I released v3.1 in 2014, it has done a very good job preventing any traffic stream from hogging bandwidth. No matter what I do DLing or ULing, all streams share the bandwidth fairly (almost equally). I can have multiple GB downloads and uploads going with none blocking any others. Interactive response is still very good. Identified isochronous traffic is very smooth. DNS and NTP traffic are very timely. Low priority bulk traffic (such as P2P) can use any B/W left after all higher priority packets have been sent. It isn't perfect. Or complete. But it does work well. And is still designed for non-experts; they need to know some technical stuff, but most of the jargon and arcana are hidden from them.

Linux's Traffic Control is poorly documented and leads to impossible expectations. I designed a nice JS-based configuration tool that I eventually abandoned because LTC just cannot do what the documentation says. However, once I really understood what it can do and what it cannot do, I was able to 'fix' traffic control so that, for the most part, traffic flows smoothly. LTC also cannot easily control multiple interfaces; for example, a gigE NIC might be able to 'block out' a 100Mb/s NIC when they both 'send' to a 10Mb/s internet link.

I haven't addressed buffer bloat. 'ls -lstr /' through an SSH connection results in ^C being unresponsive for 5-10 seconds. But dealing with that much output doesn't happen too often.

In short, there *are* Linux-based routers that do a nice job of enforcing bandwidth sharing. And some of them are free.

Design for security

Wol — Wed, 13 Feb 2019 16:41:04 +0000

> No. I'm speaking about one endpoint device (an intern's laptop?) displacing all other users. As far as I'm aware all sane routers will not allow this.

And where do I buy said sane router?

My home internet regularly collapses under load. The cause clearly seems to be down to my (reasonably modern) router. And I strongly suspect that actually the cause is the link from there back to the ISP router.

There is a VERY long-standing bug in equipment called "buffer bloat" where a single end-point device *can* displace all other users, and there's probably a hell of a lot of equipment still out there that suffers from this. New versions of the linux kernel work around this, but how many devices are still sold brand-new with old kernels, or haven't been upgraded in years?

Cheers,
Wol

Design for security

otpyrc — Mon, 11 Feb 2019 09:48:29 +0000

Back for me too, so probably just a temporary misguided content blocking:)

Design for security

nix — Sat, 09 Feb 2019 20:29:52 +0000

audio/video feeds present a danger to the company by themselves (except for the idiot productivity) but audio/video is so bulky just a few people misbehaving is sufficient to starve legitimate work traffic, as soon as you deal with worksites that host more than a handful of people.

Video, maybe (though frankly with the amount of documentation showing up as YouTube videos these days, you more or less have to provision enough capacity for that) -- but audio? Seriously? You work at places where bandwidth is so anaemic that compressed audio streams don't fit? Do they also not provide a phone network because the phones have too high bandwidth requirements?

Audio is almost the definition of a low-bandwidth application these days. Only terminal service is lower bandwidth, and audio streaming (as opposed to phone calls) is heavily buffered, so doesn't have the low-latency requirements of that.

Design for security

gevaerts — Fri, 08 Feb 2019 15:17:44 +0000

Earlier it said that the account had been suspended for ToS violations or something like that (I can't remember the exact wording), but it's back for me now. It also worked yesterday. It's not a geographic block.

Design for security

jake — Fri, 08 Feb 2019 14:20:32 +0000

> Umm, the youtube account linked to was just cancelled, and thus the video.

Hmm, I just clicked the link and it worked ... but here is a different link in case maybe there is a country-specific block or some such: http://mirror.linux.org.au/pub/linux.conf.au/2019/c3/Tues...

jake

Design for security

benoar — Fri, 08 Feb 2019 13:40:58 +0000

There exist no such law in France: this is urban legend to justify corporate control of the employees and arbitrary filtering. Also, it helps selling “security appliances” and provides big bucks to “security” companies.

From my knowledge, there is no clear consensus on employer responsibility for personal access, but I am not aware of *any* sentence to an employer for wrondoing of one of his/her employee regarding non-filtered Internet access. And anyway, if the employer is recognized as an operator as L34-1 of “Code des postes et des communications électroniques”, then they should provide the log to exonerate themselves, that they already collect anyway.

Design for security

otpyrc — Fri, 08 Feb 2019 11:13:01 +0000

Umm, the youtube account linked to was just cancelled, and thus the video.
Is there an alternative link?

Design for security

anton — Fri, 08 Feb 2019 07:33:12 +0000

I work at a university with about 2000 staff and about 20000 students, and we don't have any of the restrictions discussed here, and network hogging is not a problem I am aware of (not even in those days when the students did not all have internet at home or in the phone); I think there was one episode a few years ago where a virus or something was rampant in the university network, and apparently overloaded it, but the typical reason for the rare occurrences of network outage is when some piece of hardware fails (e.g. a router dies).

So my university invests in enough bandwidth to allow pretty free internet access, but does not invest in redundant routers etc.; what's different for corporate environments?

Design for security

nilsmeyer — Wed, 06 Feb 2019 09:37:18 +0000

> 1. idiots that find it convenient to replicate their whole trove of internal documents on insecure remote country websites, just so they can "work" from the nearest pub. See also all the various fooleaks, Hillary Clinton mail, and so on

Did you ever ask yourself, beyond them being idiots, why people do that?

> 2. idiots bored at work that think they deserve to listen to their favorite preacher all day round, pull 4k videos from their own NAS, etc. It's not that the audio/video feeds present a danger to the company by themselves (except for the idiot productivity) but audio/video is so bulky just a few people misbehaving is sufficient to starve legitimate work traffic, as soon as you deal with worksites that host more than a handful of people.

It's possible to manage network bandwidth without completely breaking encryption.

Of course I believe that stronger, more restrictive security measures make sense where "idiots" are involved, or even just the people who know very little about computers. What annoys me is that the same applies to people in IT (developers etc.) as well, except of course for the people who administer the network, they seem to always have a workaround. I usually refuse to work at places like that since it's hard to be productive and usually indicative of a certain workplace culture.

Design for security

nilsmeyer — Wed, 06 Feb 2019 09:24:33 +0000

They should change that law.

Design for security

Cyberax — Sat, 02 Feb 2019 20:51:42 +0000

Which ones? The firewall on Mac OS X will not disallow outbound connections. It will simply block incoming connections (possibly with exceptions for signed binaries).

You can install additional firewall software but at this point you can just as well install a full-blown management client instead.

Design for security

nim-nim — Sat, 02 Feb 2019 12:10:20 +0000

That actually works (not my domain, I haven't looked at it, but I think the desktop firewalls let pass the first few requests without filtering to let the portals show up). Or they just let google search been redirected, as that's the internet for a lot of users.

Design for security

rodgerd — Fri, 01 Feb 2019 21:51:09 +0000

They also break more security measures than they solve problems; cretins with middleboxes masquerading as security experts have done more to undermine security that most black hats could dream of.

Design for security

Cyberax — Fri, 01 Feb 2019 21:15:21 +0000

> That's trivial to handle, just deploy a firewall that forbids everything except the corp VPN when outside the corp network
Try it. Go on, try it. I dare you.

Hint: this won't work. Even Starbucks requires you to click through the captive portal page to get access to WiFi. Ditto for GoGoInflight and approximately most of other public access points.

Design for security

nim-nim — Fri, 01 Feb 2019 21:12:14 +0000

That's trivial to handle, just deploy a firewall that forbids everything except the corp VPN when outside the corp network

Design for security

Cyberax — Fri, 01 Feb 2019 20:10:39 +0000

> And that's almost exactly the processing middleboxes do, except you only need to manage a handful of centralized middleboxes, instead of getting the correct conf on (tens/hundreds) of thousands of workstations.
No, middleboxes only see network traffic. They can try to decrypt it, overcoming more and more counter-measures, but they are fundamentally limited.

If your users have laptops then the middleboxes won't see anything that happens outside of the company, when a laptop is used in a Starbucks (for example).

Management software can ensure that the firewalls are configured correctly and it has quite a bit more access to browsers (via group policies) and other software. Also if you have hundreds of endpoints, you probably should manage the client devices anyway.

Design for security

nim-nim — Fri, 01 Feb 2019 12:06:49 +0000

That depends on the complexity of your network topology. It's easy to manage on border equipments, not so much when you get closer to the backbone. And, unfortunately, humans are social beings, so you can be sure whoever invents a new way to make the network crawl to a stop, will have bragged about it to friends, that will participate in the DOSing.

Design for security

Cyberax — Fri, 01 Feb 2019 09:55:59 +0000

> So basically, network @home and network @work are not the same thing, it's different technical compromises, and all the high-volume low-security low-availability use cases people are used @home do not translate well @work.
No. I'm speaking about one endpoint device (an intern's laptop?) displacing all other users. As far as I'm aware all sane routers will not allow this.

Design for security

nim-nim — Fri, 01 Feb 2019 09:46:57 +0000

>> It's hard to design locked down workstations that do not do more productivity damage than the middleboxes.
>You don't need to lock down boxes. Just install mandatory firewall rules, software inspectors and anti-intrusion software. This can be almost completely transparent to end-users.

And that's almost exactly the processing middleboxes do, except you only need to manage a handful of centralized middleboxes, instead of getting the correct conf on (tens/hundreds) of thousands of workstations.

And if you complain middleboxes are badly configured, how exactly do you expect the same processing to be configured correctly when multiplied by thousands of endpoints or more?

It's not that is is technically impossible, but a corp that skimps on correct middlebox maintenance, is unlikely to be generous on endpoint maintenance.

Design for security

nim-nim — Fri, 01 Feb 2019 09:42:11 +0000

>> Lastly, enforcement through logs does you little good when *network hogging*
> Is it seriously even an issue these days?

Yes.

Home access nowadays can be 1 FTTH per family, so basically one high-bandwidth link for ~ 4 people.

There's no way any sane corp will provision the same per/user bandwidth ratio on any work site with 50 people or more. The economic model works for home access because its main point is to slurp high-volume entertainment, so home users are ready to pay tens of $ per month and user just to get access to their videos and games. The per user budget for network @work, where users are mostly supposed to exchange mails and access some webified corp apps, is not the same.

Add to that that a byte of corporate bandwidth is more expensive, because corps want some warranted availability (it's expensive to pay people to wait for network to go back up), and you have all the security systems trying to detect intrusions (cost scales with amount of traffic to check), while home bandwidth is dirt cheap (zero security processing, best effort availability levels, no link redundancy).

So basically, network @home and network @work are not the same thing, it's different technical compromises, and all the high-volume low-security low-availability use cases people are used @home do not translate well @work.

Design for security

Cyberax — Fri, 01 Feb 2019 08:39:01 +0000

> It's hard to design locked down workstations that do not do more productivity damage than the middleboxes.
You don't need to lock down boxes. Just install mandatory firewall rules, software inspectors and anti-intrusion software. This can be almost completely transparent to end-users.

> And even when you lock down workstations, are you going to remove browsers too?
Why would you want to remove browsers?

> Lastly, enforcement through logs does you little good when *network hogging*
Is it seriously even an issue these days?

Design for security

nim-nim — Fri, 01 Feb 2019 08:32:09 +0000

It's hard to design locked down workstations that do not do more productivity damage than the middleboxes.

And even when you lock down workstations, are you going to remove browsers too? A lot of jobs need a browser. And the cloudy data-slurping websites have been pretty good at making all their dangerous stuff depend on a browser only.

Lastly, enforcement through logs does you little good when network hogging by the local intern made one of the people/systems that rack money for the corporation miss a deadline. The money is already gone and wasted by the time you home on the culprit.

Design for security

Fowl — Thu, 31 Jan 2019 23:45:58 +0000

Bravo! Theoretical security is not enough, if never happens in practice.

Design for security

rgmoore — Thu, 31 Jan 2019 23:04:12 +0000

a system which aims to be secure has better be usable, otherwise users will find ways to workaround the security to make their life less complicated.

More precisely, though, this has to do with security making things more difficult, not with the underlying usability of the software. If your program is overall very easy to use but security adds complexity, people will work to defeat the security even if it's still reasonably easy to use with the security in place. If your program is overall very difficult to use but the security doesn't make it any harder, people have no reason to defeat it. The ideal approach is to make security have a negative cost: make it harder to do things the insecure way than the secure one (which would include making insecure impossible).

Design for security

sml — Thu, 31 Jan 2019 22:46:41 +0000

Network inspection is the wrong approach. You'll never get 100% visibility and all those crappy middleboxes (Bluecoat et al.), corporate certificates and associated complexity are a security disaster zone.

I find endpoint enforcement - locked down workstations and centralised logging - much more effective.

Design for security

tylerl — Thu, 31 Jan 2019 18:46:35 +0000

First, annoyance is definitely part of usability, and therefore security.

This is not naive at all. This is advanced stuff -- this is as advanced as it gets in the security world. It seems simplistic because the concept is simple, but this is one of the absolute fundamental truths of security that, if you work in this industry, you need to grok. She's pointing out the fundamental disconnect between what we often *think* is security (offering a mechanism by which safety can be maintained) and what security actually is: making the obvious path (perhaps the only path) be the safe path. Not just secure by default; secure under all non-exceptional conditions.

This is difficult. This is exceptionally difficult. This is my day job. I'm working with literally the most capable engineers in the world, possibly under the most supportive and favorable conditions that exist anywhere, and this is still hard to do at scale.

This means security UX needs to be involved in a significant way at the design stage of all nontrivial components. It means changing the way we think about responsibility and authority. It means you never force someone to make a decision for which they are not expected to fully understand the implications. It means security must explicitly support the "I just want to get my job done" use case -- you give your people (safely and seamlessly) the resources to do their job.

This is really, really hard to do. Far more than it seems just talking about it. But it's my experience that it's the only solution and approach that does not conflict with reality.

Design for security

nim-nim — Thu, 31 Jan 2019 18:33:33 +0000

Well you do need to inspect traffic in a corporate context. Some common examples:

1. idiots that find it convenient to replicate their whole trove of internal documents on insecure remote country websites, just so they can "work" from the nearest pub. See also all the various fooleaks, Hillary Clinton mail, and so on

2. idiots bored at work that think they deserve to listen to their favorite preacher all day round, pull 4k videos from their own NAS, etc. It's not that the audio/video feeds present a danger to the company by themselves (except for the idiot productivity) but audio/video is so bulky just a few people misbehaving is sufficient to starve legitimate work traffic, as soon as you deal with worksites that host more than a handful of people.

And you can say "it's all a managerial problem". Do *you* want managers that spend their day looking over your shoulder at your screen just to check you're using company resources correctly? (No one has managed to eradicate human idiocy so far, and it's compounded on jobs where computer literacy is low)

And yes deploying corporate certificates just to perform those checks is massive overreach, blame Google and the other hipsters that made it an all or nothing option just so they could fight their home ISP for the right to stream good quality netflix.

Design for security

agateau — Thu, 31 Jan 2019 17:59:57 +0000

I don't think it's naïve, I understand it as: a system which aims to be secure has better be usable, otherwise users will find ways to workaround the security to make their life less complicated.

So usability is a difficult, but necessary, goal to achieve, not a de-facto feature of a secure system.

Design for security

naptastic — Thu, 31 Jan 2019 15:43:43 +0000

I sat down with some friends--all of us professional sysadmins--a few years ago to learn GPG / PGP well enough that we could teach our friends and family members, get people using encrypted email, make the Internet a better place, yadda yadda. In 3 hours, we could not do secure email using any combination of FOSS email clients. We gave up, reaching the conclusion that developers working on GPG and email client plugins should seek other career paths.

Now we use Keybase and and it just works. We use our real names, actual photographs of ourselves, proofs anywhere we possibly can, and we only "follow" each other after verifying account ownership in person. (We treat "following" the same way as signing someone's public key, and make sure they understand that before following them.) The UI isn't great, and the .deb is >100 MB, but you know what? Good security is inconvenient, and having to download a 100MB .deb every other day is still a million times better UX than GPG.

Design for security

Otus — Thu, 31 Jan 2019 14:45:36 +0000

> I'm not talking about a system that has been "locked down" or "secured". I mean a computer system that is functionally indistinguishable from an inert lump of semi-precious metals.

You don't need to go that far for people to bypass the computer and get their work done by e.g. sending texts from their phone. And that's not nearly maximally secure.

Design for security

edeloget — Thu, 31 Jan 2019 13:45:22 +0000

> This is a corporate anti-pattern I've seen with a few customers where I had to install their CA to connect to some websites or click away the warnings. This usually happens through some appliance made by a proprietary vendor (who often have horrible track records when it comes to security), which is rarely if ever upgraded. It's completely compromising the security of the whole network, reducing security for everyone. The purpose of this is usually content blocking, which is also highly problematic. Some times I had a case where vital resources (documentation, test sites) were blocked, to get content unblocked you had to request it from the vendor(!).

Yet in some countries (including France) the company is responsible for the sites you visit when you are in, so that makes the whole thing a lot more complex than a corporate anti-pattern ; should they disallow HTTPS? or should they let you do anything you want, risking potential legal fallbacks?

Design for security

joncb — Thu, 31 Jan 2019 13:29:10 +0000

I think you misunderstand me. I'm not talking about a system that has been "locked down" or "secured". I mean a computer system that is functionally indistinguishable from an inert lump of semi-precious metals. There might be a keyboard or mouse but it will never have an effect. There might be a screen but it will never display anything (information or otherwise). I think you understand this because you state why this is the case most effectively. If a system can be used(i.e. has any value of usability greater than absolute zero), then there is a potential (if unreasonable) system that is more secure because any security can be undermined by the user "working around it". Yes this is akin to a thought experiment. No-one is going to build an inert mass of metal and call it "the worlds most secure computer".

My point is that it is simple to imagine counter-examples to that initial idea that "Good experience design and good security cannot exist without each other" and i think that undermines the true value of what the talk is saying the rest of the time. I would rather people acknowledge that yes, there is a tension between usability and security and the interplay between these two values is complex and thinking about one without thinking about the other is doing your users a disservice.

Design for security

nilsmeyer — Thu, 31 Jan 2019 12:00:38 +0000

> In a network context, though, users expect that their communications are able to be read only by the expected recipients and man-in-the-middle attacks violate those expectations.

This is a corporate anti-pattern I've seen with a few customers where I had to install their CA to connect to some websites or click away the warnings. This usually happens through some appliance made by a proprietary vendor (who often have horrible track records when it comes to security), which is rarely if ever upgraded. It's completely compromising the security of the whole network, reducing security for everyone. The purpose of this is usually content blocking, which is also highly problematic. Some times I had a case where vital resources (documentation, test sites) were blocked, to get content unblocked you had to request it from the vendor(!).

The solution of course is to route most of your traffic through a 4G connection...