hlandau

Here are my complaints about a Brother LED printer (HL-3170CDW):

Rasterisation:

- It supports PostScript, but the rasteriser is so slow it's a problem. If you print a PDF without any transparency in it it's fine. If you print a PDF with the slightest bit of transparency in it, expect a 30 second delay of the "Data" light blinking per page. This destroys the print speed and probably wastes toner due to not having the next page ready in time.

- Its official print driver isn't just a PPD but has some binary blob Linux executable configured as a filter. This is obviously completely unusable on non-x86 platforms. I assume the object here is to rasterise stuff on the host before sending it to the printer to avoid the above issue, but it is a proprietary solution.

- Even using the official drivers on Windows, plenty of documents take noticable time to rasterise per page (e.g. heavy PDFs containing high-DPI scans taking tens of seconds per page), and you still don't get the rated print speed. So the above doesn't fix rasterisation time anyway.

The consumables game:

- The toner cartridges for this printer are NOT chipped. This is good. It's actually incredible how it works; there is a 1 bit mechanical 'register' on each toner cartridge which comes set from the factory, and when the printer senses it, it clears it mechanically and resets some settings such as page count since last cartridge change.

- However, after accidentally buying the wrong cartridges for a newer kind of Brother printer, which had a very obvious set of electric contacts added, it's become clear that Brother is now chipping its newer toner. This cannot bode well IMO.

- Furthermore, the printer will refuse to print after a certain amount of time with a given toner cartridge. Sometimes it will detect there doesn't seem to be toner in it and you can fix this by taking out and shaking it. But, as per the service manual, there is also a hard cutoff after which it just won't print (unless you use the service mode to make it pretend you've inserted a new cartridge). According to the service manual, this is because there is a 'bias voltage' which needs to be adjusted over time as a cartridge is used, and this is reset when you insert a new cartridge. Hence why they have the 1-bit mechanical register. The problem is that their bias voltage lookup table with respect to page count so far seems to run out after the rated number of pages, so it just refuses to print after that even if you have toner in there. You can use service mode to reset this and make it act like there's a new cartridge in there, thereby resetting the bias voltage to the initial value, but I assume this is done for a reason and would lead to suboptimal results(?). So the effective result is that Brother LED printers will automatically demand a new cartridge after a certain number of pages, even if toner is remaining.

I'm currently substantially more happy with a Canon G650 tank-fed inkjet. It's been about a year now and I still haven't had to refill it, which means it consumes consumables even more slowly than the Brother. Of course one of the great things about tank-based designs are they can't be chipped and the ink level monitoring is open-loop.

I will also say the Brother is now unusable for colour printing, as it comes out all garbled. Unclear why this is, perhaps it is due to some bad third-party toner (I never buy genuine), so I'm not really holding this against Brother, but it is another downside in practical terms.

IMO printer manufacturers should be banned from selling print cartridges, and should be required to publish specifications for their manufacture instead.

Now we just need to expand this to include the right to fix software bugs - thereby banning restrictive code signing practices and locked bootloaders.

It seems to me this could also be an advantage for websites which want to make themself inaccessible in these circumstances. An enterprise which firewalls things so only port 443 is allowed out is also more likely to do corporate MitM of all traffic. Historically I was definitely annoyed that browsers chose to make custom root CAs an implicit exemption from HPKP (even if HPKP is now history). I'd certainly consider DoSing my own site under likely MitM conditions. Using a different port also makes it harder for organisations to successfully do this kind of filtering in the future if it becomes widespread.

Another advantage is to prevent other kinds of blocking, which are based on blacklisting specific ports rather than only allowing port 443. Many residential ISPs and even hosting providers now engage in the flagrant net neutrality violation of blocking port 25; if use of SVCB records became common to allow a different port to be used, it would let other ports be used for site-to-site email, allowing email domains to contribute to rendering this blocking ineffective. Of course I'm not aware of any plan to adopt SVCB for email yet. But TBQH as someone who's always lamented the Internet's lack of a decent service lookup mechanism and the limitations (and lack of adoption) of SRV records, I'd like to see SVCB adopted for pretty much everything in future.

Fundamentally the use of well known ports was always a mistake, and really was just a crutch which was entirely the product of the internet's lack of any real service discovery mechanism, aside from the late, extremely underused and very limited DNS SRV mechanism. Ports are a mere implementation/routing detail and should not have any semantic meaning whatsoever. The time when organisations can do port-based filtering is coming to an end, fortunately. (Even if they do continue with it, the ability to now move practically everything to port 443 makes it increasingly meaningless in terms of achieving whatever they thought they were hoping to achieve.)

Unrelated, but I highly recommend anyone visiting Seattle check out the Connections Museum, open on Sundays only. It has several different genuine analogue and early digital telephone exchange frames saved from being scrapped from genuine telephone exchanges. They turn them on and you can actually call from one phone to another inside the museum. The museum itself actually shares a building with a real telephone exchange. Lots of old books, technical journals and schematics too.

I just thought to post this since when I visited in September, some actual retired telecoms engineers were part of the tour group. One had been involved in the development of submarine cable technology.

Old but obligatory link, the Evil Overlord List:

http://www.eviloverlord.com/lists/overlord.html

These are called "open-channel SSDs", which seem to currently mainly be consigned to research purposes AFAICT. But some do exist.

https://en.wikipedia.org/wiki/Open-Channel_SSD

I was just thinking about something like this.

I'm not sure you'd actually need to have physical coupling from the train to the platform. Train lavatories used to just dump their contents out of the track. Given that tube trains are already required to stop at a very precise location on the platform, perhaps the hot water could just be dumped into a funnel built into the ground underneath the track beneath the rails.

Getting cold water onto the train would be harder. Perhaps a big funnel on the top of the train underneath a pipe? ;)

There seems to be a fair bit of overlap with "base-building games" (a genre I'm fond of), including base-building games which I wouldn't necessarily describe as engineering games but just more generally management/simulation/strategy games (e.g. Evil Genius, Prison Architect, etc.) - Rimworld is on the list but feels a lot less engineering-oriented than say, Factorio, but on the other hand, (Open)RCT2 is missing which is surprising.

Basebuilders seem to divide into two rough categories: ones where things you build appear immediately (e.g. RCT2), and ones where minions have to go and install what buildings you command to be installed (e.g. Evil Genius, Factorio's robots).

Recommendations for interesting basebuilders are always of interest.

While we're on the subject: games with level editors (particularly those with some kind of scripting system) are kind of interesting as even if the gameplay isn't "engineering", you can get sucked into level design. DROD comes to mind. A list of games with level editors would also be interesting.

Fixed ;)

I have an almost, but not quite, completely unrelated anecdote about this.

I got on the internet in the early 2000s as a teenager, and would often be in various online chatrooms. Tricking people into visiting "shock sites" (most famously goatse.cx) seemed to be a common habit of certain denizens of these communities, either to people they didn't like or just because they thought it was funny.

Somehow I managed to avoid ever falling victim to this, but there was one exception I recall, in which I was linked to a website purporting to be website of the "Apostrophe Protection Society". After only a moment some kind of JavaScript kicked in to instead change the contents of the page to some goatse.cx-style shock image which I don't recall. In other words, the "Apostrophe Protection Society" page just existed as a kind of bait-and-switch cover.

I quickly closed the page, and ironically what I ended up remembering is not anything about the shock image but the notion of the "Apostrophe Protection Society". I think at the time I assumed that the notion of the "Apostrophe Protection Society" was intended to be part of the joke - that nobody would ever actually make such an organisation.

I never bumped into that site again, but for heaven knows why (my memory is scary sometimes) I still remember the existence of this site pretending to be about an "Apostrophe Protection Society" (or some similar title).

So, TIL it actually is real - and actually a legitimate organisation. Presumably whoever made the above website must have picked the website at random and copied its contents. Well, I hope this random anecdote about what the web used to be like is of interest to someone...

The correct move here is not to try and plead with the EU or do other things which implicitly recognise their authority to make such regulation. The correct move here is to hold such regulations in contempt and expressly refute any claim the EU makes to regulating web browsers as illegitimate.

I may as well add that web browsers are generally open source software and their source code thus a form of speech. Recent actions by the EU have made it clear they are trying to start to exert control over web browsers, which they presumably see as prime estate for exerting control over the internet. The correct answer to this is to distribute web browsers from jurisdictions with strong freedom of speech (code) protections, remove any assets from the EU which the EU might try to take hostage to extort compliance, and respond to the EU's frequent attempts to assert "if anyone in the EU uses your product, you have to comply with our rules" with "you and what army."

Author of the above blogpost here.

To my knowledge the situation has changed nowadays and IOMMUs on smartphone SoCs are now common. Having said that I still don't rate the security of any smartphone and you should assume it will get compromised. There's a million reasons for this:

- Baseband is still radioactive and probably trivially compromised by any nation-state adversary so it's all down to the IOMMU.

- IOMMUs are hard to configure correctly and frequently misconfigured by drivers which don't use them correctly.

- Any host driver bugs in talking to the baseband might be exploitable.

- It's hard to verify an IOMMU is actually working correctly, so it's not like any of this is commonly audited.

- We're talking about SoCs here with the baseband usually integrated on the same chip, so there's always the risk of some undocumented channel between the baseband and the rest of the chip the vendor omitted to notice or tell anyone about.

The situation is at least better than it was but it's still 100% my assumption that no phone can be trusted in the face of an adversary who can put up a fake cellular network. There's simply far too much proprietary firmware, mysterious black boxes, etc. to be able to really trust these things.

Also I'm assuming here there's a desire to get access to the host processor and stored data, but you don't need to do that if you just want to get at the microphone or GPS or leak someone's location or so on. There's a million bad things someone could do getting access just to the baseband even if the IOMMU works right.

>The second, less known, reason is that between compute, storage and network, network is actually the hardest part to scale for cloud providers. Thus they need to find a way to incentive their customers to optimize their network usage by themselves. And what better motivation to optimize something than taking a huge chunk of your profits?

This doesn't really make sense as an explanation.

Cloud networking has two components:

1. The network connecting the datacentres to the internet (the datacentre edge infrastructure).

2. The network connecting the servers and virtual machines to that edge.

1 is a solved problem and the variable costs are going to be based on any transit connections used. What cloud providers charge for bandwidth here is out of proportion to that, and they don't bill for ingress anyway, so this makes no sense.

2 is a technically more complex area, except it's very clear that getting people to use this infrastructure less is not the motivation because cloud providers don't charge for intra-DC traffic. You can ferry data around between servers in the same AZ as much as you like and not pay anything. The same is true of transferring data to and from e.g. S3 and EC2.

In other words, the more technically complex and sophisticated network component is the one which isn't billed at all. Meanwhile, boring internet connectivity is billed at an exorbitant rate, but only in one direction.

It's really quite obvious at this point that the motivation is vendor lock-in. You are penalised if you take data out of a big cloud provider but not to put data in. This means as soon as you put anything in AWS you are suddenly motivated to do as much in AWS as possible.

This is fundamentally anti-competitive. If AWS starts offering some infrastructure service, it can offer free bandwidth to that service for its own customers, but some third party providing a comparable service can't, at least unless it also starts using AWS.

But that's not even the best of it. If you want even better proof that these charges are BS, just look at Snowball. This is a service where you can transfer data to S3 by having AWS mail you a hard drive. Amazingly, they have the gall to charge per GB for this in addition to the fixed fee you pay... but only for exporting data.

In other words, I can pay $150 and get loaned a SSD, fill it up with 14TB of data and import that data to S3. If I pay $300 to get data out of S3, I also pay $0.03/GB. Internet transit is not even involved here!

It is pure anti-competitive lock-in. It's also really against the principles of the internet, in that the internet couldn't have developed as it did if we accepted different billing for communicating with different IPs (can you imagine "I don't want to send traffic to a foreign IP, I'll pay international rates!"). Yet cloud providers work on this principle. If you think about it it is effectively a net neutrality violation, just not on the part of residential ISPs - they charge you less to communicate with their own services than with others (zero-rating).

>Even if Oxide goes bust, you can still salvage things in a pinch.

Is this true? Can you set your own root of trust for the firmware signing key and build and deploy it yourself?

I'm sure this will be dependent on lots of signed closed-source firmware like Intel and AMD platforms, but there's always room for NVIDIA to surprise me, break character and do the opposite. It would attract a lot of people to the platform who want or need open firmware.

DDoS protection is standard among hosting providers now, including budget ones like OVH.

The fact that Cloudflare is allowed to continue hosting websites which are obviously illegal, some notorious, is deeply strange. As I wrote in my article on the subject, it makes no sense when you consider the way the US responds even just to copyright infringement; see how they nuked Megaupload's business without trial because they saw them as knowingly enabling piracy. However, it's a known fact that US authorities will keep illegal or disreputable services up if they see them as a source of more intelligence. I can't really see any other explanation for how Cloudflare is allowed to host some of the sites it does without pressure from the US unless it's basically funnelling all of the data to the NSA.

My understanding is that COVID happened and schedules slipped, and as a result they decided to licence some IP blocks from Synopsys (like a DDR4/5 PHY and a PCIe 5.0 PHY). Synopsys likes including control MCUs in their IP (yes, their DDR PHY has a MCU in it) which are intended to run a binary blob provided by them, and for which they will not give you the source code. For those curious, it's the same DDR PHY blob needed for memory bringup used by the i.MX8M and products based on it (e.g. Librem 5).

Basically IBM facing delays chose to use the IP of Synopsys rather than make their own DDR5 and PCIe5 IP as they usually would (the fact they traditionally made all their own stuff is one of the reasons they were in the position to open 100% of the firmware of POWER9 in the first place), and dropped the ball on making sure that would meet the 100% open source firmware requirements of Raptor's customers. IBM walled themself into a corner here, as they're now dependent on Synopsys IP and it's not like they can persuade Synopsys to open their ahem precious IP.

See my article (it was a hypothetical but has now been confirmed): https://www.devever.net/~hl/omi

(Of course the DDR PHY is on the OMI chip not the CPU, but with only one supplier of the required OMI chips this is a moot point. The PCIe5 PHY is on the CPU though and also needs a blob.)

You can try to see if your provider supports "opaque" types in which you can submit the binary encoding of the record without them knowing what it is. Barring that you'll need to request support for it. It's an increasingly popular record type so not supporting it isn't terribly great service nowadays.

I'm not familiar with the discussion that went into the design of CAA (it was probably discussed at some point on the relevant IETF mailing list, if you want to go digging).

Both you and the grandparent are correct in that both propose viable attacks; it is a known fact (and not news to any expert in the space) that "domain validation" certificates are vulnerable to "global" MitM in which an attacker can intercept all traffic to a domain (and therefore intercept the validation probes). A situation in which a service's hosting company is sitting on their "front door" (so to speak) and MitMing all traffic that goes their way is exactly such a situation (hence my recommended mitigation).

Right, they could do this and this seems like a good idea to me. The problem this require-CT behaviour isn't switched on by default for basically any TLS library, so an XMPP client developer would have to go out of their way to switch this on, and I assume most or all (currently) don't. That can change of course.

So I assume DLT is a generic/more general term for blockchain technology.

There's this thing called Zooko's triangle (https://en.wikipedia.org/wiki/Zooko%27s_triangle), basically the premise that an identifier can only have two of the following properties: secure, decentralized, human-readable.

But a blockchain can actually be used to square this triangle and get all three. The original example of this is the Namecoin project, a fork of Bitcoin using a lightly modified Bitcoin codebase which can be used as a key-value store.

The idea is that a blockchain can be used to create a decentralized database mapping keys (domain names) to values (which can be things like IP addresses, but also PKI trust anchors, similar to DANE). Thus this can eliminate the need for a CA. You can also use it to map human-readable names to .onion addresses. There is also root-of-trust transparency built in since the contents of the database is public and any changes are also public. The right to change a key-value entry belongs to the public key of the person who registered that key. Nobody can override this. Namecoin domain names use the .bit (unofficial) TLD.

It's a really neat technology and also makes things like censorship via domain suspensions, your registrar getting hacked, etc. infeasible.

Full disclosure, I previously worked on the Namecoin project, I authored the DNS resolution daemon and the technical specification for the format of DNS data in the KV store. Unfortunately public interest in the project has waned, and deployment is the real issue - you have to have the client software to be able to resolve these domain names. There is at least some conceivable possibility Tor might ship it in their bundle in the future though, so people could type example.bit in Tor Browser to get to a hidden service. The project remains active though.

As a 16:9 refusenik/16:10 holdout it's pretty disappointing how, with the possible exception of LCD backlights, the 16:10 display panel offering remains basically the same as it was in 2006, and hasn't inherited any of the upgrades that the rest of the display industry have produced since then, like 120Hz or HiDPI. Seeing 120Hz be considered not "high refresh rate" nowadays though is certainly a surreal feeling.

Will 16:10 continue to be treated like an unloved stepchild? Can vendors really just not wait to kill it?

Small update: I've just written a blogpost with my thoughts on the incident. https://www.devever.net/~hl/xmpp-incident

I usually brood on blogposts for days before publishing them since I care a lot about getting things accurate, but this is a bit of the moment, so here goes. Always happy to get feedback by email or IRC: https://www.devever.net/~hl/contact

Yeah. I used to be 100% in on DANE and against CAs. I'm still 100% for DANE but I now think DANE using existing CAs is the better option in many cases because it means things get CT logged. We don't have a DNSSEC transparency situation right now. OTOH there is one undersung issue with CAs, which is that Let's Encrypt isn't as universally available as people think (see the US embargo list) and that does potentially make access to the internet harder for some.

There are some use cases where DANE is actually winning real victories and is actually more viable than the existing CA infrastructure - site-to-site SMTP, for example.

>Using CAA is a good idea in general, but would it help in this case? The attacker would just request the exact cert configuration that is permitted by CAA. Maybe this helps if you can strengthen one validation method?

Author of ACME-CAA (RFC 8657) here. ACME-CAA can mitigate this because you can put a unique identifier for your ACME account in the CAA record, so it is not possible for an attacker to do this unless they can get your ACME account private key (or coerce the ACME service). This assumes you have DNSSEC-secured nameservers, of course, otherwise DNS requests can potentially also be intercepted when queried by the CA.

See RFC 8657 for a full list of security caveats. The RFC is designed to be more readable than most.

Blogpost by me with more background: https://www.devever.net/~hl/acme-caa-live

In what way is this a standard?

Where can I read the specification?

There is a comment here by the author of this patch which is absolutely extraordinary:

https://lore.kernel.org/lkml/20230731083806.453036-6-hch@lst...

"Given that symbol_get was only ever inteded for tightly cooperating modules using very internal symbols it is logical to restrict it to being used on EXPORY_SYMBOL_GPL and prevent nvidia from costly DMCA circumvention of access controls law suites."

This is literally an attempt to claim the protection of the DMCA's anticircumvention law (which makes it illegal to "circumvent" DRM) for the Linux kernel, an open source project. It's also a tacit admission that EXPORT_SYMBOL_GPL is blatantly a DRM scheme (which it is).

Personally I loathe NVIDIA and have no particular interest in defending their behaviour; however, I find it extraordinary here that the Linux project is trying to claim the DRM anti-circumvention law applies to an open source project. It's pretty bizarre given there are few laws which seem more universally opposed by the open source community, and seems to me quite at odds with the values of FOSS - as is any DRM scheme.

>"It can’t be that an Ed Sheeran stream is worth exactly the same as a stream of rain falling on the roof," Warner Music Group CEO, Robert Kyncl told Music Business Worldwide earlier this year.

Why not?

>My web searches around that are eerily silent, and the best technical explanations I could glean tend to show that measured boot and discrete TPMs are fundamentally incompatible.

Indeed. It is actually remarkable how the TPM implementation on PCs has been blatantly insecure for most of the lifetime of the TPM ecosystem (with fTPMs only being relatively new), and remarkably few people pointing out this obvious fact.

Honestly there are so many issues with the PC TPM ecosystem I have a draft blogpost going through them all, but it might be a while before I can finish it.

Sure, this is fine.