d2mw
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
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
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
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 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)
Non-marketplace AMIs are built on public EBS snapshots, but that's something they should still fix. Marketplace AMIs already handle private snapshots
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
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)
That is literally how Adobe Air was billed
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.
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...
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
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
(these downvotes are confusing. Do you disagree that it is marketing? That their approach is brutal? That they plan this regularly?)
"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
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
- 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