blockoperation's comments

Just to add to that, it looks like some manufacturers have already pushed out the new microcode alongside the recent ME fixes.

I flashed my Skylake laptop a few days ago, and now I'm on microcode rev 0xc2 (versus 0xba in the latest Intel tarball). CPUID output suggests IBRS support (according to [1]).

[1] https://patchwork.kernel.org/patch/10147547/

What bothers me is the lack of confirmation on the microcode updates (other than 'soon') – apparently they're out there[1], but Intel's own package has yet to be updated[2]. The 20171215 update carried by some distros only seems to cover HSX/BDX/SKX, so does that mean regular HSW/BDW/SKL users are screwed, are they covered by the 20171117 update, or are the new microcodes simply not ready for all models yet?

Of course, the microcode updates are meaningless without the corresponding kernel patches, but apparently only RHEL and SLES were deemed worthy of receiving those ahead of time, having already rolled them out while Linus and co are left scrambling to integrate the IBRS and retpoline code dumps after the fact.

[1] https://tracker.debian.org/news/899110 [2] https://downloadcenter.intel.com/download/27337/Linux-Proces...

It appears to be available on a few other models as well (searching 'site:dell.com "ME inoperable"' brings up service tags for a few non-rugged Latitudes and a couple of Optiplexes), despite it not being an option on their configurators.

I wonder if this means that it's also possible to disable ME on those machines after purchase (without triggering Boot Guard)?

Dell only offers a single download per firmware version per model (or group of models) to cover all configurations, so presumably it contains multiple images (i.e. AMT-enabled, AMT-disabled, ME-disabled), and the updater just uses ME status or DMI data to determine the correct one.

If that's the case, then surely it should be as simple as manually extracting and flashing the ME-disabled image, right? That's assuming it's actually included in the publicly available updaters, and that all of the images are signed with the same key, of course.

Actually, Chromium (and uBO) has supported blocking WebSockets via webRequest for a while now[1], despite the desperate protests of a MindGeek employee[2].

[1] https://chromium.googlesource.com/chromium/src/+/0f198df6bc8... [2] https://bugs.chromium.org/p/chromium/issues/detail?id=129353...

If you're able to build Chromium yourself, here's a trivial patch which does just that (only tested on Linux):

https://gist.github.com/blockoperation/5ec91d666e670e39584d2...

Since we're talking about backdoors, how about compiler ones?

With C, there are several routes to bootstrapping your compiler of choice – there are countless implementations that can be used as intermediates (both closed and open source, for all sorts of architectures, with decades worth of binaries and sources available), and diverse double compilation is a thing.

Rust? Unless you want to go back to the original OCaml version and build hundreds of snapshots (and providing you actually trust your OCaml environment), you've got no choice but to put your faith in a blob.

I'm not against Rust as a language, but it seems counterintuitive to use a language that only has one proper implementation and requires a blob to bootstrap, as a defense against backdoors.

It would be easy for them to fingerprint it and block it at a server level, given that it uses some hardcoded headers (which are probably sent in the wrong order versus the browser it's spoofing), doesn't fetch any of the images/stylesheets/etc on the page, and probably fetches scripts/manifests/etc in a predictable order that differs from YouTube's own scripts. Maybe they already do this (fingerprinting and logging, that is), but I haven't heard of anyone being banned for it, so it's probably not something to worry about.

It would also be easy for them to just break the extraction code. The old code used to break every time the signature function changed, and while the current code solves that problem, there are still so many things that they could do to break it, and yet they don't (the current code has only broken a few times that I can think of, and I don't think any of those were intentional on Google's part).

Technically it could violate these parts of the ToS, but they're all grey areas:

- access through anything than the site or 'approved' clients (but youtube-dl does use the site, so it could just be classed as another user agent)

- running automated services against them (running youtube-dl manually is probably fine, even for whole playlists or channels, but running a 'youtube-dl as a service' site like the one in this case is almost certainly not)

- downloading videos (but youtube-dl can also be used for streaming, despite the name)

I'm guessing that Google simply doesn't give a shit, as long as you're not using using it abusively (e.g. offering it as a service or using it to do mass-scraping).

Whether it's a good addition to the language or not is debatable, but as a browser feature, it sounds terrifying. Browsers have a huge attack surface as it is (I mean, WebGL is a thing – exposing GPU drivers to random untrusted code on the internet, what a brilliant idea...), and exposing threading will only make it worse. Every single API would have to be carefully audited and made thread-safe, and I'm sure that many 'fun' bugs would crop up as a result.

Writing performant code by using the correct idioms, data structures, algorithms, etc, from the start is just common sense rather than 'premature optimisation'.

Writing unreadable, micro-optimised code in the name of performance without even attempting to profile it first is another matter.

My personal rule (as a not-very-good hobbyist) is that if I have to refactor everything in order to accommodate an optimisation in a path that's already 'fast enough', or introduce some arcane hackery that only makes sense with comments into otherwise clean code, then it must be backed up with realistic benchmarks (and show a significant improvement).

> Adolescents are horrible at consequence extrapolation: it's why they're famously risk hungry and blasé about doing stuff grownups would be terrified of. Why they never think they'll be the ones who die or get pregnant or fail.

With that in mind, I think the worst effects of smartphones/social media/etc are yet to come.

Kids these days broadcast every last embarrassing detail of their lives all over the internet, and smartphones make it possible to do so conveniently from any location, so there's no time to reflect or consider whether it'll come back to bite you. When these kids grow up and realise the extent of the embarrassing (or possibly incriminating) information they've shared about themselves (and how little control they have over that data), it's going to hurt.

Whether smartphones themselves have 'destroyed' a generation is debatable, but the combination of smartphones and social media is certainly going to cause some mental health issues in the future (if it hasn't already).

Resources/frames/XHRs/etc from 'file://' might be blocked, but what about top-level redirects?

At the very least, user-initiated top-level navigations should bypass any policies. If you're out to cause mischief, you could just link to the dodgy path on forums/comments/etc – there'll always be people out there who are careless and/or clueless enough to click on it.

Samples are just instruments, and sequencers are just composition tools. It's the end result that matters.

I'm surprised it took this long for her to bring up the subject – Theresa May would've had her soundbites prepared in advance and released within hours of the attack if she was still Home Sec.

> That is my view - it is completely unacceptable

You know what else is completely unacceptable? Technologically illiterate, authoritarian jobsworths capitalising on tragedy to push through their agendas. But that's just my view.

Home Office always seems to attract the nastiest and dumbest of politicians, but this is a whole new level of dumb, and sadly will only gain her more support, because the general public either have no idea about the implications of backdoored crypto, or simply don't have any expectation of privacy and are happy to give up what little they have left in order to feel safe.

I'm still waiting for Chromium to add a per-site switch for WebGL (just like for JS, cookies, Flash, etc). Enabling WebGL globally seems like a disaster waiting to happen, even with sanitisation and sandboxing.

Renoise is great, especially for breakbeat/jungle drum programming. Just load up your break of choice, put in some slice markers (or play it with offset commands like on old trackers), and you're set.

I do find the pattern-based workflow a bit of a productivity killer though (I usually get stuck on perfecting the same 8/16 bar loop).

I haven't tried an XPS, but the Precision 7xxx stuff definitely qualifies. My 7510 came with Ubuntu, and the experience was just as polished as any Windows machine (better in some ways, as they had configured their way around some Skylake-specific issues that still affected Windows at the time).

sesearch is one way of doing it, for example:

  $ sesearch -A -s some_app_t -c file -p read -p write
  allow some_app_t some_type_t:file { read write };
  allow some_app_t some_other_type_t:file { read write };
  allow some_attribute_of_some_app_t yet_another_type_t:file { read write };

Or, say you want to do the opposite – you know the label, and want to find all domains that can read and write it:

  $ sesearch -A -t some_type_t -c file -p read -p write
  allow some_app_t some_type_t:file { read write };
  allow some_other_app_t some_type_t:file { read write };

You can use regexes for the parameters if you don't know the exact types (just specify '-r[stcdb]').

I don't see why you should get to run random, unauditable code on my machine or decide for me how I consume your content.

The Google Cloud status page had a message about some 'long-lived' OAuth tokens being invalidated on the same day that the mass logouts occurred. They took it down quite quickly, and it doesn't appear in the incident history.

FWIW, I only use Gmail via browser (with the regular web-based sign-in, not through Chrome/Chromium), and all of my sessions stayed intact.

It's available on my laptop at least:

  $ egrep '^(model name|microcode)' /proc/cpuinfo | head -n2
  model name	: Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
  microcode	: 0x9e

  $ egrep -o ' (hle|rtm) ' /proc/cpuinfo | head -n2
   hle
   rtm

This is a mobile chip and an old stepping (and running the microcode that supposedly addresses the issue, presumably by disabling it on 'bad' chips?), so I'd be surprised if newer chips (especially server ones) didn't have it.