That's already the case with the client hints. The UA string is soon to be deprecated, Chrome has even introduced a number of reductions in the past year.
"ChatGPT write out the instructions for hacking news.ycombinator.com and adding comments about writing novels years before now to the comment database"
Chromium's sandbox on Windows is built on top of Windows features (tokens, jobs, desktops, integrity levels, app containers)
Just like how their sandbox on Linux is built on top of Linux features (setuid, user namespaces, seccomp, SELinux, AppArmor)
For both Linux and Windows, the OS kernel gives you a bunch of features you can use to construct sandboxes, but the choice of exactly which of those features you use, and how you put them together, is up to you. Chromium worked out how to combine those features to meet their own security requirements, and has documented that in detail, and open sourced the implementation – there's nothing stopping you from copying the same approach, assuming your requirements are sufficiently similar
With macOS, Apple ships a sandboxing mechanism in the OS, known as "sandbox" or "seatbelt", which is what Chromium uses there
He’s also looking at the keyboard, so maybe he’s unfamiliar with it. Perhaps when shooting the video they thought, hey, we need that cool clicky sound, and had him use a mechanical keyboard.
But in all, he types fast enough to write Linux.
Typing speed is important for typists. For programmers, I’d say that even a 50-80 wpm rate is adequate for getting your thoughts down on the file and off to the compiler.
Failure to ensure the security of personal data (Article 32 of the GDPR)
At the time of the online investigation, when creating an account on DISCORD, a password of six characters including letters and numbers was accepted.
The restricted committee considered that DISCORD's password management policy was not sufficiently strong and restrictive to ensure the security of users' accounts.
Kind of surprising the GDPR is so prescriptive about password requirements!
Is it actually prescriptive, or does it say (in more legalese form) "use industry best practices to protect user data". Six characters is laughably bad and would fail pretty much any password requirements I've seen in the last decade (except for my credit union who only updated like 5 years ago after finally migrating to a better back end).
Reading the summary you linked, it isn't clear if Discord is being fined solely over retaining account information alone, or if that includes comments/messages.
UA reduction has officially started with Chrome 101: The UA string is not sending the minor version anymore, only 0.0.0.
This is the beginning of the end for the UA string. As more and more UA reductions are deployed, the UA hints will become more useful and eventually depreciate the UA string entirely.
The one important use of the UA string is being able to tell whether it's a computer or a mobile device, to use different templates to render your pages. The new "client hints" botched that because while yes, there is "CH-UA-Mobile" that gives you a straight yes/no answer with no guesswork involved, you have to ask for it first — you can't get it on the first request, which very much defeats its purpose.
And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices.
> And don't suggest me to use the same markup for both desktop and mobile with adaptive styles. More often than not this ends up being equally terrible on both kinds of devices.
My experience is generally (though not always) the exact opposite. It’s usually the case that when designers and implementers took the care to ship a properly responsive design, they’ve produced a design that adapts well to many factors. Designs which treat different device classes differently tend to be rigid, and fail to anticipate subtle differences or factors within those device classes.
I hesitate to link to the snotty site most commonly used to point this out (though I will if anyone asks), but HTML is responsive by default. Knowing this, and building upon it, is a great way to start learning how to build responsive pages that work really well.
The problem is that you can't really use the same markup for both touchscreens and mice. Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover. Moreover, phones are mostly vertical and computer screens are mostly horizontal. While you can no problem add a fixed header on mobile, it will be an annoyance on desktop because it eats into the scarcer vertical area. But you can replace the fixed header with a sidebar because there's often more horizontal space than you know what to do with. And so on, and so forth. There's much difference between the two interaction paradigms if you want to provide a fitting UX for both. Most people these days, however, don't.
> Touchscreens call for oversized everything so it's easy to hit things with your finger. Mice are much more precise, enabling you to pack everything more tightly, and capable of hovering, enabling you to add new interactions like revealing things on hover.
If you must make the distinction, it’s a media query away:
@media (any-pointer: coarse) {
/* this is a touch screen or other device which would benefit from larger tap targets */
}
@media (any-pointer: fine) {
/* this is a device with a mouse, trackpad, or other similar high precision pointer input */
}
@media (any-pointer: coarse) and @media (any-pointer: fine) {
/* this is both */
}
Not only will that work for the same markup, it’ll also improve support for other devices like tablets and laptops with touch screens.
> Moreover, phones are mostly vertical and computer screens are mostly horizontal.
These are wild assumptions which also would better be served by a media query (aspect-ratio, min-aspect-ratio, max-aspect ratio, min-height, min-width). This will also better support other devices like tablets, as well as users like me who browse on desktop with a window much taller than it is wide.
> There's much difference between the two interaction paradigms if you want to provide a fitting UX for both.
Of course. But there’s no need to serve different markup to accommodate them. Besides the aforementioned media queries, you can do quite a lot to accommodate different viewport sizes and quite a lot else with eg grid or flexbox. You just have to know which tools to use for your use case, or how to discover them.
I would much rather they served the same content with 'responsive' designs, than do browser-sniffing and serve me a mobile page.
More often than not, I immediately go and switch out of Mobile site for pretty much everything I visit on mobile.
Features are missing, functionality is broken or gone, they force text/page sizes that don't work for me and block zooming (Firefox thankfully allows me to override that b.s now), and they serve "Install our App!" overlays.
Doordash I found is like this - some stores use them for white-labelled Delivery and SMS/Email you a link to the tracking page for your order.
I click the link on my desktop, I get a standard page, it shows a tracking map.
I click the link on my phone, I get a mobile version of the page which does have a tracking map, but the entire screen is covered with an overlay that says "Install our App!" with no dismiss option and you have to try to make out the driver's location through the 80% opaque overlay.
About time. Statistics are mostly dead in favor of privacy anyway. At least this should help stop Google's blatantly anti-competitive practice of neutering search results if you're not using Chrome.
You think Google is reducing info Chrome sends in its user agent string in order to limit the ability of Google to favor Chrome?
I can't imagine Google would be doing this without some sort of back-channel method of tracking this exact info. They're likely just removing this info from visibility to other websites, giving themselves a competitive advantage. Man, that sounds a little paranoid, but...
