I have a load of these shell aliases as I spend a frankly ridiculous amount of time messing with git. `g` is `git status`, `d` is `git diff`, `gad` is `git add`, `ds` is `git diff --staged`, `gg` is `git grep`, `gbv` is `git branch -va`
Compared to the amount of code that people compile and the number of bugs seen and fixed in that code, that is a tiny number of bugs. I wouldn't say it's "never" a compiler error but when you find a bug in your program, it's almost certainly not the compiler's fault.
Yep, for me the reason to go with Hue is that the bulbs have good CRI, good colors, and the colors match between all the different types of fixtures. I've also not had a single Hue bulb fail in the 6 years I've been using them.
In some places it sounds like the ONT is integrated with the router (like with DOCSIS), and being forced to use the ISP’s router is a problem.
But in cases where the ONT just looks like a media converter and you have a separate router I really can’t see any reason for the customer to provide their own ONT. Especially given PON is a shared medium so a misbehaving ONT can affect other customers.
> But in cases where the ONT just looks like a media converter and you have a separate router
That's how it works in New Zealand, but we take it a step further. The GPON/XGS-PON fibre network is run by a separate company[0] from the ISPs (and the company running the fibre network is prohibited from providing internet services[1]). So the ONT just functions as a media converter[2], and all our ISPs deliver internet over the same fibre network. This decoupling between the fibre network provider and ISP means you can change ISPs without any swapping of ONTs or repatching of fibre[3][4] (in fact, the process can be entirely automated, switching to some ISPs can take effect within an hour or two of placing the order). That and most ISPs allow bringing your own router (as there's no monopoly in the ISP space).
[0]: The NZ Government contracted four companies to build, own, and run fibre networks (three being new companies co-owned by local lines companies and the government to serving their local area, with the rest of the country being served by Chorus, the company that owns the country's copper network). These fibre companies are heavily regulated (including how much they can charge ISPs).
[1]: In fact, this requirement resulted in Telecom (the company that owned our copper network and who was one of the companies that provided phone and internet service to consumers) being split up, with Chorus being spun off, owning the copper network and owning the fibre network for the majority of the country.
[2]: Chorus did start deploying ONTs with a built-in router/AP a while back. They did offer this to ISPs to use, but uptake was very low, so it's since been discontinued.
[3]: I don't know how it works over in European countries where ISPs run their own fibre networks when switching ISPs, I assume they have to either install their own fibre line into the premises or the existing fibre is repatched to their network?
[4]: The fibre companies are required to offer use of their fibre network directly to ISPs, with the ISPs PON network running in parallel to the fibre company's, with the ISP providing their own fibre splitters and ONTs (which would be run on a second fibre line that each premises already has) and running their own OLTs. I believe this requirement still exists, but no-one ever took them up on it.
About [3]. In Switzerland most of the fiber network is built by Swisscom, a former telecom monopoly and still 51% state owned company that also owns the old copper network. Other ISPs can use the network but everyone has their own router with an integrated ONT. ONTs as a separate device are pretty much unknown. On XGS-PON only certified ONTs are whitelisted [0] The wholesale price list is public [1] For actuall prices see [2] They differentiate mostly through support, price and additional services like TV. Data caps are basically unheard of (I don't call something like the fiber7 FUP of 600TB a data cap) and CGNAT is, while not uncommon, at most a phone call to disable it.
I am curious about this model. How well is this working in practice? How many ISPs do you have to choose from, and how do they differentiate? How close to wholesale are the retail prices?
I believe the number of ISPs differs regionally (I suspect due to where they have network equipment), but I just put in my adress into the main search website (https://www.broadbandcompare.co.nz) and it came back with 13+ ISPs (although some of them might belong to same parent companies). Prices tend to be quite similar (which I suspect indicates that it is operating close to cost) and differentiation happens mainly on bundling with other services (mobile, power, TV, included Netflix...) Keep in mind that I have only lived here for 1.5 years, but from my limited experience it definitely seems like there is a healthy amount of competition.
Chorus does let ISPs handover in just a single or a couple of points to provide service nationwide (well, for the areas they serve), instead of needing to do it at all 27 handover locations. I imagine it's possible to interconnect with the other fibre companies over a backhaul connection as well. So smaller ISPs can definitely offer service nationwide without having to put networking equipment all over the country.
My understanding is that the margins on fibre connections for ISPs are quite slim. The three big telcos do both broadband and cellular, and they definitely try and push customers with lighter needs over to wireless internet delivered over 4G or 5G (which has more margins for them). There has been a bit of consolidation among the major players (one of the big telcos (2Degrees, who do both broadband and cellular) merged with one of the big broadband-only telcos (Vocus) a couple of years ago). But there's plenty of smaller ISPs. And a couple of the electricity retailers have gotten in on providing internet as well. And it's not uncommon for local WISPs to offer fibre as well.
Differentiation between ISPs is definitely mainly on cost, quality of support, and bundled services. They all have their own networks (the fibre companies only provide L2 connectivity from the customers to the ISPs), and there can be some differences there. For example, another of the big broadband+cellular telcos (Spark, who was the ISP side of Telecom before they were split up) is the only major ISP that doesn't offer IPv6 and doesn't peer at local peering exchanges.
Some ISPs have cheaper plans with data caps, but many ISPs don't even offer data-capped plans, and everyone offers uncapped plans. Similarly, most ISPs let you use your own router. And about the only variation in how you'd need to configure your router is PPPoE vs IPoE/DHCP and VLAN 10 vs untagged. So you can usually switch ISPs and all you need to do is maybe change your router config.
As a side note, of particular interest to the audience here is the existence of a new-ish residential ISP (Quic) that offers things like static IP for a one-off cost, /28 IPv4 subnets, self-service rDNS management, and self-service access to the ONT status, connection logs, etc. One of the advantages of having competition in the ISP space.
It seems to be working quite well in terms of ISP choice (see my reply to cycomanic). And Chorus is offering up to 8 Gbps connections over XGS-PON, with most of the other fibre companies either also offering XGS-PON or working to offer it.
I suppose there are a couple of downsides compared to being able to use your own ONT, in that residential customers can't get SPF ONTs, and Chorus's XGS-PON ONT is quite large and not wall-mountable, which has caused a few people to hold out on XGS-PON offerings (they're working to offer a smaller one, but it got set back a bit, and they also won't start offering it until they run out of the old XGS-PON ONTs). But that's all quite minor (a residential customer wanting an SPF ONT is very niche indeed, as is a genuine need for a residential XGS-PON connection).
> In some places it sounds like the ONT is integrated with the router (like with DOCSIS), and being forced to use the ISP’s router is a problem.
I agree, and that is a problem. The rules and regulations are different in different countries. In Austria for instance the ISP can force you to use a specific DOCSIS modem or ONT but they have to provide you with a transparent way to connect to it (bridge mode etc.). Which from where I'm standing is a good tradeoff because it gives the ISP the flexibility to do mass migrations without having to consider very old deployed infrastructure.
With PON I think it doesn't matter all _that_ much but for instance people running ancient DOCSIS modems and limited frequency availability has been a massive pain for people stuck with DOCSIS infrastructure that want more upstream and can't.
So at least in Portugal, my ISP gives me their device, it has a bridge mode, but it also serves as their wifi access point network (think Xfinity wifi) -- which I don't object to except that their wifi can't be disabled and their signal interferes with my wifi access points.
I want a dumb gpon sfp not because they won't give me a bridge, but because their bridge makes too much noise.
I have to wonder, why can't their wi-fi be disabled? Is it one of those scenarios where it is being used to support other ISP customers in your area?
My ISP (note: also owned by my employer) doesn't have this, so the modem I've got is theirs, but I can disable wi-fi. I do, too, so the only client on this thing is my firewall. I assume that everything past my firewall could potentially be hostile.
> Gleichzeitig gibt es eine gesetzlich garantierte Endgerätefreiheit (Art. 3 Abs. 1 TSM-VO). Auf Grund dieser haben alle Nutzer:innen das Recht, einen Router ihrer Wahl zu verwenden. Stellt der Anbieter einen Router mit integriertem Modem zur Verfügung, muss es möglich sein, diesen Router in den sogenannten "Brigde-Modus" zu schalten.
> Because the Wifi 6 enabled Modem from Magenta doesn't support bridge mode.
It does. Call customer support and they enable it for you. It turns into a dumb modem afterwards behind which you need to put your own infrastructure.
I replaced my Google fiber ONT by cloning the network parameters into a cheap SFP one because the Google supplied one only supports gigabit Ethernet but uses 2.5/1.25gbit optics. The upgrade reduced latency a small, but measurable amount, and improved my NTP jitter.
In theory the ONT can act like a listening device. They're also often Linux or BSD devices that can get hacked.
If you're paranoid, you may want to run an ONT that you control, just in case. I doubt it's something that matters to a lot of people, but even if it only matters to some, it shouldn't be made impossible for those that want to.
RE: misbehaving hardware: the same is very much true for cable internet and there are plenty of countries where people hook up their own modem without any trouble. If someone wanted to mess with the fiber network they could just disconnect the ONT and shine a laser pointer down there. All off-the-shelf devices are built to just work and follow the necessary standards, because there's nothing to be gained by messing with the PON network like that.
> In theory the ONT can act like a listening device
Sure, but so can the other endpoint. Even many AON installations these days are just hidden XPS-PON and similar, you just never see the ONT. (See a lot of ISPs in Switzerland)
Definitely agree. The smart place to demarcate the connection is the point at which a device does DHCP/SLAAC to get whatever IPs the ISP assigns the customer.
If that’s the argument against, it could just be denied by default and require the user to go into settings to allow. The annoyance isn’t too bad given webserial is probably only used on occasion, and it means no concerns about consent spam or fingerprinting.
Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them, and being able to access a serial port is a niche case where it does make sense -- just like accessing a web cam or microphone. It's certainly less annoying than the one for allowing push notifications.
Unless, of course, the site is malicious/spammy. It's possible to do all kinds of annoying things, from triggering consent dialogs, to opening new windows, to playing sounds.. and you can even do them in a loop. Adding (or not) a consent dialog for webserial doesn't change that.
> Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them
And that is the result of a lot of hard work and pushing back on... well, on things like this. There are already enough that many people have been trained to click Accept without reading. Any new source of consent dialogs must be scrutinized very closely.
> being able to access a serial port is a niche case where it does make sense -- just like accessing a web cam or microphone.
If you agree to webcam access, then the site can see and record you visually. If you agree to microphone access, then the website can hear and record you aurally. If you agree to serial access, then your "TSMX9200b7 Larangipone GmbH" can... er... do something? Maybe it can turn on a blinky light. Maybe it can capture audio through an embedded IoT microphone (or speaker that shares wires with something else). Maybe it can use the debug interface on something you didn't realize had a debug interface to reprogram the device to emulate a keyboard or ethernet device and hack your system. Are you going to whitelist devices owned by big companies with lawyers and screw over experimenters? Blacklist devices so the well-behaved hackers won't hack you?
I wish we lived in a world where we could just add consent dialogs or config settings to allow things like this. Instead, we live in a world where if something like this is enabled, you'll get phishing emails with support tips for fixing your browser issues (or slowness) by going to about:config and twiddling some setting that is meaningless to the 1% of recipients who matter.
Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things. If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.
> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.
With software that users install, there's at least the fact that users sort of vet the software they install, and there's a somewhat restricted set of software that is running.
However, even in a fully sandboxed environments like phones we know that users don't read the dozens of permissions that apps require. They just click yes.
However, even when there are attempts at restricting software like Windows UAC and MacOS's security warnings, we know for a fact that users don't read those warning and permission dialogs.
And this is for systems with a rather small restricted set of software.
Web sites are whatever link you click in the browser. There's not even the installation step. They just run. Including any and all advertising networks (all those 11472 partners for your privacy): https://en.wikipedia.org/wiki/Malvertising
> Those same phishing emails can just ask you to install some random non-browser software or activate any number of other insecure things.
Yes, because those native apps have access to a much larger attack surface. (As in, they already have all the permissions they need to do major harm.) Which is why OSes have their own scare screens when installing software, and why there's been some success in educating people that installing random shit they come across on the internet is not necessarily a great idea. (Unless you're installing the 432nd dependency of your CLI npm script. Then it's fine.)
Wouldn't it be great if we had a native app where you didn't have to worry too much about what people install, but could still run arbitrary code hosted anywhere? In the limit, you could make it so a single click—on a piece of text, say—would make it do a network request to pull down the arbitrary code and execute it, with no consent required! You'd just sandbox it so that if it needed to do anything requiring extra capabilities, it'd pop up a consent box. Of course, you'd better make sure it's not popping up too many when doing normal things, because then people would just start automatically agreeing to everything that popped up. And it's not just the number, it's also whether the consent popup describes what is being requested, why, and what harm it could cause, in a way that makes sense to nontechnical users. Which means you probably don't want to use it for things where you can't explain it well enough, since then it'll boil down to "will you allow dji@@fo&suR?JGkgslf.##!14* in order to do the thing that you want to do?"
Of course you will. If it was dangerous, then it wouldn't give me the option, right?
(For the sarcasm impaired, I am describing a web browser.)
> If you are trying to protect a user from going far out of their way to follow instructions they are handed by the enemy you simply can't win.
If we were talking hypothetically, I would agree. (And in fact, I do agree that we can't win. At least, not forever and not in all things.) But this isn't hypothetical! This stuff is happening, all the time. And when someone agrees to allow something that can do DMA to main memory and corrupt random bits of data, I have to debug that shit. Or more likely, someone has the great idea to dynamically load a shared library that does Super Secure Antivirus Stuff, which of course the user will agree to, and then I'll have to debug the crashes that result from the buggy thing crapping all over its nest in the browser's main process address space and hooking into things without delegating to any existing hooks. Hey, it worked fine six browser versions ago on the OS version from last year! If that sounds like an unlikely and rare case, then how unlikely is a random bit flip? Because we see ton of crashes from those every day. (Hint: if read-only memory that's supposed to contain code that lives on disk doesn't match what's on disk, then you can't really blame it on buggy code flipping a flag bit on the wrong address.)
> Users aren't presented with a "barrage" of consent dialogs. There's not even that many of them, and being able to access a serial port is a niche case
It's amazing that you write this and then immediately find the (almost) right answer:
> Unless, of course, the site is malicious/spammy. It's possible to do all kinds of annoying things, from triggering consent dialogs...
And then immediately dismiss that as if that wasn't a valid concern:
> Adding (or not) a consent dialog for webserial doesn't change that.
Yes, yes it changes that. It increases the number of consent dialogs in a system that already has a few of those, and where users are already trained to click "yes" to thousands of annoying popups.
Oh, and these are not just empty words. Recently Mozilla relented and implemented WebMIDI. Guess what: https://x.com/denschub/status/1582730985778556931 It didn't even require a malicious/spammy site. Just regular ad networks.
