Society is only one Android release away from most consumer traffic metadata being tunnelled by default through a new instrument of political policy, thanks to a company who not so long ago wouldn't even let you select which _search engine_ you used. Do you really suppose the same company will start adding URL input boxes to their initial setup screen? If they even put such a text box in the settings, what percentage of users would actually customize it?
So the effect is not just the local mobile telco's DNS would be subverted, but every mobile telco's DNS, and if you tried to explain what's happening to the typical person it impacted, they'd give you a puzzled look before promptly switching the topic to last night's football game. Thankfully this is a completely fabricated scenario and there is no possibility whatsoever it could even remotely play out.
Given this one scenario, what value or weight does a single bearded guy's raspberry pi stashed in a closet have when it comes to worldwide DNS policy? I wonder how resilient a site like The Pirate Bay would be given an environment where DNS filtering is suddenly under the majority control of a tiny handful of companies all under American or western ownership. But DoH of course is about freedom, not about censorship. It's about preventing censorship, right!
(Apologies for the style of reply -- these are obviously not genuine questions)
I can't see into the future, unfortunately, but you're welcome to bookmark the parent comment and set a calendar entry to compare it with reality about once every 6 months. It's possible to speculate, though. Google have been engaged in open war against ISPs for most of the past 10 years, it is in their every interest to commoditize the pipe between the consumer and the datacentre as far as possible. Removing DNS from the link is eliminating another source of risk
For Mozilla, I'm not sure, but they often follow Google's lead, and there is a strong case for Google to go that route
In any case if it ever starts defaulting to on in any browser, it's very likely the others will follow suit, as it's easy to imagine quite a lot of PR around the security benefits of the brave new world
you appear to have jumped to step 2 in the masterplan, and completely skipped step 1. It's not even mandatory yet, but when it is, the choice will be between N<10 providers, most of them almost certainly American companies
They can fight it on the basis of censorship, and I'll support them on the basis of a decentralized Internet that does not rely on some folk who leaked private data all over the Internet a few years ago.
Fuck DoH. It's political and technical centralization under the tired old banner of "freedom!" when reality is absolutely the opposite. It'll be abused in a heartbeat the moment it has majority share, assuming folk like CloudFlare don't already have people working full time on how to profit from the data, or formulating policies on which sites they shut down that they never hosted in the first place
If you're new to this game, it always progresses the same tired old way:
- it's optional, you don't need it, but if you use it your life will become 1000% better and starving orphans in China will learn about democracy
- we're using it for just this one particular service you might need it for but it's fine because that particular service is totally optional and you have a "choice" between 3 vendors who all accidentally depend on this new thing, because they're all playing the same game
- we rolled out a new feature but it's only available to newer clients, you probably genuinely do need this feature, and the choice to avoid the new service seems to be less and less appealing
- we don't have people working full time on the older product any more, and it's full of bugs, and we're struggling to support it
- we've made some commercial agreement you weren't expecting that interacts somehow with our adjusted position thanks to the new service. somehow you've become the product without any warning, but you're so far down the river it's much less effort to stay put than try to undo becoming the product
- we've encountered a bug and made a huge negative PR fuss around the old service. it's officially insecure and you will catch cancer if you continue using it
- [3 months later] we're deprecating the old service
What I mean is https://i.ibb.co/P6N35qv/Screenshot-from-2019-08-10-10-27-25... does not make it clear whatsoever that 'public' really means public. Before we get into blaming the customer, there should be a bright red warning label in that dialog. Consider that English may not be the first language of many users reaching that screen
I think they have it for some stuff elsewhere, but it doesn't seem unreasonable to make public snapshots a per-account permission that defaults to disabled, and requires an interactive UI checkbox to enable. Out of the millions of AWS accounts, public snapshots are legitimately useful to maybe 1000 tops
For EBS, step 1 is reading the docs, step 2 is cutpasting a documentation example.
For S3 I'm not sure how people are building their lists. AFAIK the API provides no enumeration. So this is possibly something coming from web crawl data (e.g. common crawl)
Public EBS snapshots are great, and thankfully a design other clouds didn't copy. I've found all kinds of stuff in there, including a 900GB Oracle backup of a publicly traded manufacturer's accounting system. It doesn't require much imagination to understand how this kind of data could be profited from, given relatively low effort
It seems unlikely a lot of people didn't already know about this, it's hard to miss even if you only spend a few days with the EC2 API, and it's also quite surprising AWS have yet to correct the design. 90% chance it is mostly a UI problem -- there are no warning labels around snapshotting in the EC2 UI
Google can claim many firsts, but hopping from a baseband to an application processor most certainly isn't one of them. I'm sure you can find presentations from e.g. CCC much older than 2017
It's unusual but certainly not novel. There have been similar attacks against e.g. server network cards >10 years ago, where (IIRC) a magic pattern used for factory testing could put the card into firmware download mode, and from there it had access to RAM, so game over
It's only in relatively recent times that shared memory interfaces have fallen under the security spotlight as new scenarios arise where a trusted driver may not be speaking to a trusted piece of hardware (e.g. virtualization), so there are plenty of attacks around that involve hopping across an interface assumed to have been free of trust boundaries (Firewire is another example kinda like this)
Pwn2Own fell out of the spotlight over time because they managed to piss off sponsors and teams alike, not because any material improvement occurred in software security, involving systems that for the most part continue to be millions of lines of C just like they were in the 90s. Security processes have improved tremendously in recent times, but software security in general has advanced only incrementally at best, such that individuals can still succeed at breaking the majority of software, and are able to do so with such reliability that the practice is done as a sporting event.
Per the slides over 150 of those kernel bugs resulted in code execution, and that is already a lowball count of the true number. Upstream Linux, being possibly the most visible and well-resourced OS codebase around, even by 2019 does not have the tools necessary just to automatically find the bugs we already know exist.
If SCM_CRED passing were a real problem in _any_ scenario, SELinux should target that instead, not an entire subsystem on which half the system is built
One reason to dislike SELinux is the arbitrary assumptions baked in by default that barely anyone knows how to or cares to change, which makes carefully designed software look broken when the framework itself is broken. One example I've faced is UNIX pipes, which for all purposes were obsoleted by UNIX domain sockets in the mid 80s as part of the original intent of the BSD socket API, but to SELinux they are profoundly different things. You can pass pipes across a user->root boundary but not a socket.
To the end user, they only see your code broken by SELinux, and assume you haven't done your job. On the other hand, SELinux is codifying rules about UNIX that never existed and amount to emotional heuristics about the risk of Internet domain sockets being inherited around the system by the wrong process. The effect isn't to prevent Internet domain sockets being inherited by privileged processes, but breaking all sockets. That's garbage design, hidden behind marketing suggesting because the NSA contributed some code that the problem couldn't possibly be SELinux
The western world has sad tendency to believe its ideals are the only ideals, so you're unlikely to attract much productive comment. Fanaticism is found everywhere, it's just common for some cultures to give it another name when convenient
So the effect is not just the local mobile telco's DNS would be subverted, but every mobile telco's DNS, and if you tried to explain what's happening to the typical person it impacted, they'd give you a puzzled look before promptly switching the topic to last night's football game. Thankfully this is a completely fabricated scenario and there is no possibility whatsoever it could even remotely play out.
Given this one scenario, what value or weight does a single bearded guy's raspberry pi stashed in a closet have when it comes to worldwide DNS policy? I wonder how resilient a site like The Pirate Bay would be given an environment where DNS filtering is suddenly under the majority control of a tiny handful of companies all under American or western ownership. But DoH of course is about freedom, not about censorship. It's about preventing censorship, right!
(Apologies for the style of reply -- these are obviously not genuine questions)
edit: these unexplained downvotes are fascinating