VEARS is about reporting POTENTIAL adverse affects. It takes analysis to extract signal from the noise in VEARS, to see if the event is statistically different in occurrence to the background rate of the event being reported. This sort of analysis is how TTS was discovered for AZ. Similarly myocarditis with Pfizer.

VEARS is a tool. You can use it correctly or incorrectly. Citing single events being reported there as evidence that there is a problem is using it incorrectly. Reporting potential observed side effects is using it correctly, be it I felt really crook through to a person died and everything in between. Using the data set as a whole to look for anomalies is correct use.

No vaccine is 100% safe. Every single one has risks. They all have benefits too. Taking a vaccine is a risk benefit analysis.

With COVID-19 vaccines the analysis clearly comes down on the benefit side. I took AZ just after the reports of TTS where coming in. I knew that the was about a 1 chance in a million that I could die from an adverse reaction. I also knew that my chances of dying from COVID-19 where 1000's of time higher if I didn't have the vaccine. I also knew that it is inevitable that I would get COVID-19 if I didn't take the vaccine as none of the vaccines are good enough to generate herd immunity with 2 doses (the jury is still out on 3 doses).

Just about everything you do in life has risks and benefits. Do you drive to the supermarket? There is a risk that you will die in a car crash on the way there or back. You will get less exercise. There are also benefits like it takes less time. You can bring home more goods.

Australia has nuclear reactors https://en.wikipedia.org/wiki/... and before that https://en.wikipedia.org/wiki/....

Actually many ISP turn on DNSSEC validation.

Actually you can do DNS over UDP and not get successful cache poisoning. It does require using DNS COOKIE and falling back to TCP when the server doesn't support DNS COOKIE.

Note: the paper greatly underplays the availability of DNS COOKIE. It's supported by multiple vendors and 15-24% of authoritative server support DNS COOKIE in the 4 years since it became a RFC.

Yet, I've charged my iPhone from my MacBook USB-C charger. Yes, there are lightning to USB-C cables https://www.apple.com/au/shop/.... Yes, it is a slower charge as the intermediate voltage is not available on the MacBook USB-C charger, but it works. When traveling I have the USB-C charger connected to the MacBook which is in turn connected to the iPhone.

Given the traffic to Pornhub will be using a privacy address, which are ephemeral, on anything anywhere near recent, it will just trace back the /48 in IPv6 exactly the same as it traces back the the /32 in IPv4. No more, no less.

To get more specific you need to maintain connection logs which are equally applicable to IPv4 as to IPv6.

When public/private fails the public often bails out the private side of the contract. Seen this many, many times.

There is nothing magically better about private, public/private, or public. It's all about how the project is managed and how realistic the costs are when the project is initially scoped.

The advantage of public is that it only needs to cover costs verses making a monetary return for investors. The returns to the public come in reduced costs rather that cheques every 6 months.

Actually the firmware doesn't need to upgradable, you just need to be able to set and save the current date occasionally to non volatile memory. The device could do this itself periodically after synchronising itself. Yes, there is a small risk of spoofed GPS signals causing an anomalous date to be saved but even there the risk can be minimised. Time more that x seconds since last recording, more that y seconds of continuously synchronised signals. For mobile GPS devices more that z km's of travel as well while switched on.

A running system shouldn't fail across a GPS epoch event. Given this is not the first epoch event all of the equipment should have been able to handle this. This can be simulated in QA testing prior to releasing the firmware image.

Well our servers use DANE and TLSA records so they don't fallback if the site has published the record.

MTA-STS depends on DNSSEC working while, paradoxically, claiming it is needed to avoid DNSSEC. Go analyse the protocol.

The majority of the worlds authoritative server to recursive server DNS lookups are DNSSEC validated today though the result of that validation may be "insecure". MTA's that support DANE also validate DNS responses. There was never a need for MTA-STS. Just deploy DANE. It isn't subject to the attacks MTA-STS is.

And which calculations are those? Actual examples of where it is *needed* for real problems not theoretical examples.

For timers you calculate a timer assuming a negative leap second at the end of each month in a interval so you don't overshoot, fire the timer then reset it to fire again with the leap second adjusted time as the base. Repeat if necessary (requires intervals over ~200000 years initially).

You read them by saying each value and using the word colon. fd93:7065:ab8e:: is eff dee nine three colon seven zero six five colon ...

FD00::/8 is the equivalent of RFC 1918. You pick 40 random bits (toss a coin 40 times, tails=0, heads=1) and append them to FD to give you a /48 prefix which is your site prefix. (e.g fd93:7065:ab8e::/48). You then have ~65000 /64 subnets to use.

That said your ISP will delegate you a prefix using prefix delegation. Typically it will be a /56 which will give you 256 /64 sized subnets which your routers will automatically assign to links as needed. The ISP is allocated IPv6 address space from the RIRs with the assumption that they will hand out /48's to customers. If the /56 is too small complain to your ISP as they have more space to give you. If your ISP only gives you a /64 find another ISP as they are not doing the correct thing.

See RFC 6698, The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA

This is a solved problem. You just need to use the solution.

It is and the ACCC fined large telcos and made them pay back the differences between the plan the customer was on and the plan that was achievable on the link. Customers that were affected could also cancel their contracts with no penalty for early termination.

The ACCC also drew up new advertising guidelines which require ISP's to advertise the rate achievable in peak times.

Going forward, if after connection, it is found that the rate you signed up for is not achievable on the link you can downgrade the contracted rate to what is achievable or pull out of the contract.

https://www.accc.gov.au/public...
https://www.accc.gov.au/consum...

They announce the battery program within days of it being reported that older iPhones were running slower in benchmarks on the iOS versions that have the code that restricts the clock frequency.

Yes, it was a coincidence. You are seeing conspiracies where there are none.