d2mw

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)

edit: these unexplained downvotes are fascinating

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

- [1 year later] captivity achieved

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)

Who on Earth is thinking that it is a good idea to take an EBS snapshot and make it public?

Non-marketplace AMIs are built on public EBS snapshots, but that's something they should still fix. Marketplace AMIs already handle private snapshots

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

I didn't recognize the story until you corrected the path. https://news.ycombinator.com/item?id=1242831

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)

It makes cross-platform desktop development much easier.

That is literally how Adobe Air was billed

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.

we all know that it's basically impossible to attack a modern well configured system

Where in the world did this fantastic idea come from?

https://events.linuxfoundation.org/wp-content/uploads/2017/1...

https://en.wikipedia.org/wiki/Pwn2Own#Summary_of_successful_...

https://threatpost.com/baseband-zero-day-exposes-millions-of...

I'm curious about how these things are expected to scale..

1000 subscribers, dedicated support person

5000, ???

10000, ???

At some point these community efforts must grow back into a company again, right? And the cycle repeats

Tears of joy.

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

Don't worry about it, I'm sure it's in the backlog

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

They pay a team to embarrass competitors. The technical aspect is a small part of what is happening here.

Project Zero has always been disguised marketing, and IMHO an extremely nasty form of it. I have no doubt they plan coordinated releases like this on a regular basis

(these downvotes are confusing. Do you disagree that it is marketing? That their approach is brutal? That they plan this regularly?)

Lambda is the antithesis of frictionless development, most of your life is invested in figuring out the Lambda way to do things, just like App Engine before it

"I just need to run this function every 10 minutes"

.. (3 blog posts later)

.. (1 lunch break later)

.. (5 Git commits across 3 repos containing a mix of CloudFormation, CloudWatch and Terraform, 3 new IAM policies and 12 S3 buckets with completely unmemorable names)

.. 5pm, oh shit, I haven't actually written the function yet

offset the deploying mechanism and control (probably to varying degrees) to a third party that’s dependent on another third party

This sounds exactly like working inside any big company, and all that pre-canned infrastructure is a huge benefit to any project

It will be interesting to see what they've built in the cold light of day, and whether it delivers. I'm apparently not nearly as pessimistic as others on this thread

I'm no Java ninja, but a few things jump out of https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/19fb8f93c... :

- at least one heap allocation for every line. After it finds the EOL it first uses 'new String' followed by '.toString()

- the C++ version will almost certainly be backing on to memchr() behind the scenes, which will be using SIMD instructions where it makes sense (e.g. large enough scan size, probably true in this case). the Java version is a manual bytewise-coded loop.

- the C++ version is reusing its output buffer, no reallocations assuming the same string length or less

No idea about encodings in Java, maybe that is playing a role too

You can find much slower machines able to route gigabit, the limitations are mostly on the bus and ability for the driver/chip to efficiently process notifications. We're only talking about 125MB/sec, and if any of that is bulk data utilizing the full MTU, as few as 81k packets/sec, represented in (modulo driver/chip/config) far fewer than 81k interrupts/sec