Before a policy is announced, we don't want to pre-empt the process of consultation and policy development, and an announcement will be made in due course. After a policy is announced, it's time to move forward with implementation, not quibble about details that are water under the bridge now.
The policy of tracking critics of government policy and shunning them was never announced.
Democracy is predicated on an informed public. The government therefore needs to be transparent and accountable to the people. Being silent so they can feel like they're allowed to do whatever they please is only acceptable in an authoritarian society.
They've been caught red handed engaging in wrongdoing and refusing to explain themselves. There's no possible excuse for that.
Definitely should be checking certs, though I always worry about the flip side of these device security decisions. if there is no way to update the trusted root certs, your TV becomes terminally ill with software ewaste disease when the manufacturer updates stop coming.
I really don’t like hardware becoming waste because we don’t have a better iot cert pool update story
I trust YouTube to know how to bake their own cert and trustworthy tls libraries into their apps but I’m not sure if that’s common in other apps
At that point, cut all its connections from the Internet and use it as a dumb panel. Many people will say you should have never connected it in the first place anyway.
You can alway use a streamer box (custom Linux one, Apple TV, Fire Stick, etc) to give it "smarts".
If a property is a string in your typescript interface but a number in your external service (api, DB, whatever) the typescript compiler would not know
This is good. I felt really annoyed that Ubuntu versions of podman lagged significantly and podman's official stance is basically just "deal with it" while they provide support for every other platform.
This is one of my favourite essays and I find myself going back to read it every couple of years. Something about the mix of DFW seeming almost purely anthropologically interested in the passengers but paternally fond of the junior ranks of the crew
(Edit - the question is now different so my comment is stale)
My understanding is power is expended when current flows through a metal with resistance, and that loss is in the form of heat. The lower the resistance, the lower the loss and therefore lower the heat
When you start with 10 elecrons on the left of the wire and none on the right and end up with 5 on both sides, you lost all energy that was stored in the system.
I don't see why a browser would "just trust" that because it is a private IP - the TLD is what matters. When you hit an internet TLD you should play by internet rules, when you hit a LAN TLD (or IP range) you could play by LAN rules. The judgement being decided by where the domain in the http request, not the final destination of any DNS lookups
If you directly went to 10.254.127.1, or some-domain.lan, that should validate differently to going to accounts.google.com
The exact issue I explained - for you it would be a local IP, even if the actual destination is anywhere else => no checks.
> TLD is what matters
bankofamerica.com.lan
It can't be used in the wild, compared to bankofamerica.com.security.itdept.xyz in the email, but it opens a way for a directed attacks to be way easier. Especially considering the awful security record of most 'SOHO' routers out there.
Sure, you can respond with evil bit set to zero for IoT devices...
Just to be clear I mean if the browser bar says accounts.google.com, you get the internet "level" validation. Regardless if the IP resolved by malicious dns is 10.0.1.1
This would be an extension of the recent HSTS preload list trend of associating a particular TLD (e.g. .dev) with a particular mechanism, and would not affect other tlds than (say) .lan or ip ranges
Do LAN sites need HTTPS? IE wifi router, printer, fax control panel?
I am pro-HTTP for these use cases for as long as browsers have more serious warnings against self signed certs, old SSL/TLS versions and weak algo choices than the warnings for HTTP.
Hardware deserves to be supported as long as it physically works rather than as long as its embedded TLS stays supported
> Do LAN sites need HTTPS? IE wifi router, printer, fax control panel?
Of course. All traffic needs to be encrypted. Why must these not be encrypted?
> I am pro-HTTP for these use cases for as long as browsers have more serious warnings against self signed certs, old SSL/TLS versions and weak algo choices than the warnings for HTTP.
IMO, HTTP-over-TCP support should have been removed from all browsers years ago, solving your self-cert vs HTTP problem.
Good solutions for the LAN use case have been rather weak so far. The two categories of solutions are a) a CA for your LAN. People are OK using this for things like dev servers on localhost, but what you want is to have router that issues DHCP leases also issue IP certs for local devices. b) TLS-TOFU for self-certs. We can even do this over the public web too, but we can also treat self-signed certs on LAN vs. public web differently and report when the identity behind the IP has changed. (Generally a bad idea over the public web because we want to allow key rotation, but that might be fixable by adding multiple keys or some hack like publishing the next key into .well-known/next-key or something -- I'm riffing here.)
> Hardware deserves to be supported as long as it physically works rather than as long as its embedded TLS stays supported
Why? Or put differently, if the manufacturer has stopped providing firmware updates, they've unsupported it no matter what the rest of the world has done. Why should the rest of the world compromise security by design in order to only partially not-break a hardware device that the manufacturer doesn't support? In this one exact scenario? Maybe in the future we can provide a small ethernet-to-ethernet (or wifi-to-wifi) device that wraps a single old TLS device and provides a modern interface to it, if support is that important.
The argument I have in favour of not requiring encryption is best summarised by what you have outlined. It would require a massive industry shift towards no obvious solution with no backwards compatibility that doesn't solve anything
Until I hear a convincing story of how I will do the usual lan tasks of
- connect to my router to fiddle with settings
- see the management interface on my printer
- join my parents network and do things for them without having to explicitly trust a CA
- And most importantly, see consumers who don't understand any of those things be able to do these things all out of the box
I can't see how it is a viable expectation
I totally love encryption. It's great. But seriously: what domain will I visit to fix my pppoe settings. Who's going to control that domain, and who's going to renew the certs for it. Because if the answer we will expect consumers and SMEs to trust a certificate authority created by a factory with its own crappy security practices, I'm not sure how that's an improvement
Otherwise we are breaking things to "fix" something that doesn't "fix" anything. if someone is MITMing my lan, it doesn't matter whether my router is TLS or not. it's compromised
- we don’t comment on individuals
- we don’t comment on hypotheticals
- we don’t comment on anonymous sources
- we don’t comment on politics.
TL;DR we don’t comment on anything, ask someone else!