I just wound up using translucent ones which came with them, with the LEDs set to solid colors to group functionality together, and a legend on the display. Zoom keys blue, lights yellow, etc.
I had an XKeys strip for a previous iteration, which included similar keycaps. My hand-written labels were ugly, so I skipped them this time around.
I've done something pretty similar with an Adafruit Macropad, Karabiner Elements (and Zoom's global hotkey support), hass-cli, and a few esphome-loaded ESP32 devices. Physical audio/video mute, raise hand, lights, speaker/headphone switch, and screen lock buttons are wonderful.
After the EMV liability shift date (October 2015), the fraud liability for a card-present, non-EMV transaction falls on the party which was noncompliant, the issuer or the merchant. Hopefully this will be a significant driver of EMV adoption by both issuers and merchants.
Comcast simultaneously claims that some of their own VoD services -- services delivered via your cable modem, through your router and home wifi network -- don't count, because they're part of your cable service, not the internet, so they're allowed to treat them differently.
The alternative is for Comcast to buy enough transit to receive those bits from Netflix. I'm sure Netflix would be happy enough to deliver those bits to Comcast via transit, if enough capacity was available.
Shouldn't Comcast be required to purchase enough capacity to provide high-quality service to their residential customers? SFI between a content provider and an eyeball network should be a mutually beneficial cost reduction, but Comcast has enough market power (captive broadband subs) that they can get away with intentionally not buying enough capacity to serve their customers.
Assume Comcast has about 10 Tbps of traffic at peak, single-counting all traffic that transits AS 7922 (Comcast's national backbone network). [1] Now assume that a full 50% of that traffic is originated by Netflix, and the market price for transit is $2/mbps. The percentage is likely quite lower than that, and given 5 Tbps of traffic volume and coordination between the two networks to reduce the number of miles the bits need to be hauled by both networks, the per-megabit price is almost certainly quite a bit less.
But even with these obviously flawed guesses, we're only talking about $120mm/year in costs. Netflix's worldwide revenue in 2013 was $4.3b [2]; Comcast's 2013 revenue from their US HSI business alone was $10.3b. [3] If 50% of Comcast's $10.3b business was in jeopardy, don't you think they'd find a way to absorb that $120mm?
I don't think so. It's multiple direct 10GE ports. Given the traffic volume the two networks exchange, there's no way it would be economical to move these bits over a public peering exchange (which Comcast doesn't participate in in the first place).
Even so, if it were in fact going via the IX, you'd see Netflix's IP from the exchange (206.223.116.133) as hop 8 in the traceroute.
There are only a handful of buildings where you need to be in order to just be a cross-connect or switch fabric away from nearly every network in the world.
You're seeing this because that's where Comcast primarily buys transit and peers with other networks; those edges are where the congested ports are. They generally have plenty of capacity between SV1 and their CMTSes (even if they have to take you from Oakland to Sac-town to get from SF to San Jose).
This is a route leak, plain and simple. Don't forget to apply Occam's Razor. All of those sites which are "coincidentally" misbehaving are located in the same /24.
This is what is actually happening. Virgin Media peers with Cogent. Virgin prefers routes from peers over transit. Cogent is turrible at provisioning and filtering, and is a large international transit provider.
Let's look at the route from Cogent's perspective:
BGP routing table entry for 199.58.210.0/24, version 2031309347
Paths: (1 available, best #1, table Default-IP-Routing-Table)
54098 11557 4436 40015 54876
38.122.66.186 (metric 10105011) from 154.54.66.76 (154.54.66.76)
Origin incomplete, metric 0, localpref 130, valid, internal, best
Community: 174:3092 174:10031 174:20999 174:21001 174:22013
If Cogent was competent at filtering, they'd never learn a route transiting 4436 via a customer port in the first place, but most likely someone at Lionlink (54098) is leaking from one of their transit providers (Sidera, 11557) to another (Cogent, 174).
Also, traffic passing through Switzerland is a red herring -- the poster is using a geoip database to look up where a Cogent router is. GeoIP databases are typically populated by user activity, e.g., mobile devices phoning home to get wifi-based location, credit card txns, etc. None of this traffic comes from a ptp interface address on a core router. GeoIP databases tend to have a resolution of about a /24, whereas infrastructure netblocks tend to be chopped up into /30s or /31s for ptp links and /32s for loopbacks, so two adjacent /32s could physically be located in wildly different parts of the world. More than likely, that IP address was previously assigned to a customer. The more accurate source of information would be the router's hostname, which clearly indicates that it is in London. The handoff between Virgin and Cogent almost certainly happens at Telehouse in the Docklands.
If someone were, in fact, trying to intercept your traffic, they could almost certainly do so without you noticing (at least at layer 3.)
Openness won in the early iterations of online services in part because there was a neutral medium over which you were able to connect to your choice of service: the PSTN.
The entire premise of that paper is misguided. It's fairly common for large providers[1], e.g., BT, Sprint, T-Mobile, to use several of the non-Internet-connected DOD /8s for management addresses, once they've exhausted RFC1918.
Actually, you'd be surprised -- Comcast is leading the charge on the residential IPv6 front in the US, and Time Warner Cable isn't too far behind. Verizon, the largest carrier in the US not owned by a content company (by my back-of-napkin math), has been slower in deployment of IPv6, by contrast. (OTOH, since IPv6 is critical to LTE deployment, VZW et al have been much quicker on the uptake.)
I actually think that the content hosting folks are behind the curve here. Amazon is one of the biggest hold-outs; their IPv6 rollout has thus far been a total joke. No IPv6 for Cloudfront? No IPv6 glue for Route53 authoritative nameservers? No IPv6 on VPC, barely on EC2 at all, etc., etc. From what I've heard, the management at Amazon doesn't really care about the network behind their infrastructure; instead of investing in building a backbone that could do a better job supporting this kind of stuff -- and all kinds of inter-region applications which would be useful -- they want pretend the network doesn't exist and that nothing needs to change. It's too bad. I think we'd see more IPv6 usage if Amazon would get their act together.
I had an XKeys strip for a previous iteration, which included similar keycaps. My hand-written labels were ugly, so I skipped them this time around.