Work on sure..
Not take advantage of larger screens no.

A well written site/application will scale well to a larger screen, or provide a completely separate UI that's suited to such a screen and its associated input methods.

Nothing is free, you pay for it one way or another wether you like it or not.

Remember when ISPs offered email accounts and webhosting space as a part of the subscription plan? Imagine a return to that where ISPs can compete to offer such value-add services, or you can buy from a dedicated supplier, or you can self host etc. Much better than a system that's centrally controlled by a single entity/

It breaks the business model of most centralised social media and services like gmail etc, but that's probably a good thing.

Remember when people had email accounts that came with their ISP subscription? You're a paying customer with rights, not a single member of a large herd of cattle being led to the slaughter.

Social media can work the same way, there are federated systems where you can self-host, or you can choose from a number of different providers that will host it for you.

On every mouse with a scroll wheel i've seen it was possible to press the scroll wheel, which every os ii can think of interpreted as a press of the middle button.

No they don't.
It might appear to have a single button, but the entire area is sensitive to touch so pressing on either side results in a different action, with the default settings making it behave like a traditional multi button mouse. The mouse also supports swiping - up and down like a traditional scroll wheel, or side to side as well.
Same with their touchpads - they look like a flat surface with no buttons, but they can behave like any number of buttons depending where you press, how hard you press, multi finger touch and gestures etc, and it's all pretty configurable.

No, changing the default is trying to push the user to make a specific choice. The next step is often to force them.
The option can already be disabled, the users already have a choice, there is no need to change the default.

Exactly, many do not filter this traffic because they just (falsely) assume such traffic will never arrive.
Test it out for yourself.

There's no such thing as "private IP"... There's nothing to stop the ISP from using reserved address space and even hosting services there for their customers to use, and many do just that because it saves on costly public addressing. All legacy space is routable when you control the path.

AWS does not enable v6 for EC2 by default but does support it.
But many other AWS services do indeed have v6 enabled by default such as route53, cloudfront, s3, etc.
For s3 and cloudfront at least you can't turn it off (you can suppress the DNS records but that only serves to degrade performance for legitimate users, someone who knows what theyre doing can trivially work out what the AAAA records should be and force them)... Because of this if you're doing any kind of logging or IP-based access controls then you need to be v6-aware and you need to ensure that your logging/acl system doesn't break when fed a v6 address.

Windows has it enabled by default, so does macos, so do android and ios. Various embedded devices have it enabled by default too. If you're running a legacy network and have anything newer than 2000 connected to it then you have the chance that v6-enabled devices are there and the communication between devices over their link-local addresses is not only possible but might already be happening without you even realising it.

In short - you have v6 devices wether you like it or not, you can either ignore it and leave a blind spot which could be exploited, or you can learn about it and incorporate it into your security model - and the only practical way to do that is to implement it properly. As a bonus you can decrease your AWS costs by using v6 instead of legacy ip.

You will find that most PCI QSAs and ASVs completely ignore v6 - they are also highly ignorant of it and will generally not even notice it's there. If you give a dual stack site name (eg www.google.com) to almost any PCI vendor they will just scan its legacy address and not scan the v6, nor will they even warn you that v6 was present but not scanned, they just completely fail to notice that it's there - which is a bright flashing neon sign that you should be using a more competent vendor.

It gets an address on the LAN interface and will accept packets with any destination IP because it's a router and will forward those packets based on its routing table. What makes you think that it would treat packets arriving on the WAN interface any differently?
If it receives a packet not destined for its own address, then it will try to forward that packet to its destination unless it has explicit rules not to.
There are many routers that do this, Linux will operate this way by default (packets not destined to an address assigned to the host enter the FORWARD chain rather than INPUT).

If your WAN interface uses PPPoE then this isn't a concern as it's a point to point tunnel and you only have to worry about the ISP itself, not adjacent customers.
If it uses IPOE with DHCP then it can potentially be a problem and you'd need to test it for yourself.
Most places never bother testing this scenario because they falsely think NAT provides a barrier.

Well it's not wrong, it's just got old training data.

More accurately, v6 needs to be ubiquitous because it's actually designed to be used for a global production network, and legacy ip needs to be relegated into a niche for retro enthusiasts.

It is legacy ip which is far more dangerous in the hands of someone who doesn't know what they're doing.

Speaking of the XSRF, here's a PoC:

This works on the default router provided by the ISP here, telnet.cgi accepts an arbitrary command and executes it as root so you can easily do something more sinister than reboot the router, the isp has many thousands of customers and most of them will be using the default supplied router, and this router vendor sells to other providers as well with only cosmetic branding changes to the firmware.
I see this exact model of router all over the place in small businesses.

This attack works because the internal address is easily predictable, and that's directly caused by nat - this attack is not practical against v6 because the address is not predictable and the range of addresses it could have is too large to brute force.

No, v6 needs to be ubiquitous. Having it only in the hands of those who understand enough to want it means that it won't be widely enabled, and thus becomes useless - eg if you travel somewhere you will constantly find yourself stuck on legacy links and thus will still be stuck with the cost/headaches of having to make your own systems reachable from such legacy networks.

Again all the more reason for more widespread use, so the bugs get discovered and pressure is applied to have them fixed.

Only thats already the case.
A lot of mobile networks have fully open v6, i can name several i have personal experience with and this has not resulted in compromised devices.
I'm aware of several ISPs that ship routers which are fully open by default, and 99% of users won't ever change those settings or even know how. This has not resulted in an increase of infected machines as modern client devices are set up to handle this, and random embedded devices are not practical to discover in the vast address space v6 provides.

I've seen many devices exploited via XSRF (see previous post), but this depends on a predictable address which nat provides, and is not practical with globally routable addressing.

That's not to say things couldn't be improved, but a default blanket "deny all inbound, allow all outbound" is stupid. This breaks p2p and is useless against today's threat profiles.
We need ISPs following the standards for v6 implementation (ie delegating a /56 prefix to users), and consumer equipment which creates separate isolated networks for different purposes.
For instance if i receive 2001:db8:100:100::/56 i would set up:

2001:db8:100:101::/64 - personal devices like laptops and phones
2001:db8:100:102::/64 - work from home (the IT dept has access to my work laptop, so i need to keep it separate from my personal things)
2001:db8:100:103::/64 - guests who visit my home (cell service sucks where i live so people are cut off if i dont give them guest wifi)
2001:db8:100:104::/64 - untrusted iot devices where both inbound and outbound is tightly controlled and restricted to specific addresses
2001:db8:100:105::/64 - kids, etc
2001:db8:100:106::/64 - voip phones where traffic is only allowed to/from the external voip provider (sip doesnt play well with nat, and a given provider can have a single v6 block vs fragmented legacy blocks so the acl is much cleaner)
2001:db8:100:107::/64 - games consoles (the xbox does p2p over v6 for certain multiplayer games)
2001:db8:100:108::/64 - cctv (i use poe cameras, so there is a risk of a physical threat actor disconnecting the cable from an external camera and trying to connect to it, so this needs to be isolated in its own vlan)

That way if anything suspicious happens and gets reported, i know immediately which vlan/ssid it came from, if you're stuck with nat then any external report is going to have the nat gateway address and while the capability for multiple ssids/vlans is realistic and already supported by some consumer hardware, the ability to log nat traffic and trace a specific activity that happened a few days earlier back to its internal address is simply not practicel with consumer equipment and would cost a significant amount to implement as you'd need to add storage to hold the logs.

In fact aside from v6, the ability to have multiple vlans/ssids is important for other reasons, such as having to operate weaker wifi security for legacy devices - eg various devices don't support wpa3 yet, and nintendo kept wep alive for many years because some of their handheld consoles didn't support anything else. What's needed is for consumer routers to support and encourage this, and make it easy to assign different access policies to different networks with a set of default profiles available - eg allow all, allow nothing, only allow one-way access from one of the other networks.

Many of them have a "dmz ip" feature which automatically forwards all ports to a specific host, its very easy to flip this on without understanding what it does.
There are also thing like UPNP that can result in arbitrary ports being opened.
Don't forget slipstream attacks either (google this).

If you're not aware if this then you've almost certainly never used v6 or managed an environment with it active, so your knowledge on the subject is extremely questionable. This in itself is dangerous because v6 is enabled by default on most things but a lack of awareness will lead to security risks.

That doesn't mean you expect to have every individual connection logged, or that the university would want to cover the cost of collecting and storing those logs.

Once you do have such logs (eg legislation in several countries requires operators to keep such logs if they're using CGNAT) then there's a commercial incentive to try and recoup some of those costs by data mining the logs and selling the data.

The rules also tend to be relaxed somewhat for residence halls - as people live there and don't generally study 24/7. Maybe porn or warez would still be frowned upon, but personal communication, gaming, legal streaming etc would generally be allowed in the residence halls outside of study hours even if not on the main campus.