Not the OP, but I have heard something similar from a sec conf before. Gist being if a laptop has stickers like this, then the chances of the owner being an engineer is significantly higher, so pentest teams / malicious actors can better focus their efforts on those individuals, and have a higher chance of gaining access to internal systems than if they targeted random folks in public.

Doesn't help as well that arguably the kind of stickers a laptop displays tends to hint at who's a sysadmin or not, etc.

That sounds like info you would already have by taking a look at LinkedIn or am I missing something?

You're missing something, but that's sorta the point. The idea of what a full-stack developer or back-end engineer or hacker (or whatever term we want to bandy about) looks like is largely based on stereotyping and a bit of myth. You can't tell what someone does for a living just by looking at them all of the time, but you can some of the time, so it's easy to play on that by dressing the part because we humans can be easily tricked into trusting our own information by default. If you cosplay as a network engineer, it's pretty likely that's what most people will think you do.

Say you're red teaming, and you are on-site looking to gain access to the server closet of a business. Some initial setup about you being there comes into play, but once there, it's up to you to look like you belong there, when some unwitting person with access to the server closet will lead you to it, then leave you to do your thing on the pleasant notion that you'll have the "problem" fixed by the end of the day. This is an ultra-simple scenario used as an example, but looking the part sometimes means having some stickers on your laptop that tell people you're really into a specific language or tool chain, or that you've been in the SOC trenches long enough to know what a lot of those inside jokes mean. Details often sell the lie.

The classic clipboard and high-vis hack.

I thought you could just measure the length of their beard.

Another commenter mentions ProtonMail, but somewhat unadvertised is with a paid Proton sub (I forget which tier), you also get access to SimpleLogin. It's a service which lets you create new email aliases with your domain that just send them to another email you own. (Also lets you send emails as that alias, so the other end doesn't see your real address.)

I use it with Vault/Bitwarden, which lets me generate email addresses of format `<uuid>@my.domain.com` when I create new login info for services.

> If you need to style something when it is stuck, why not make the css class that made it stuck include that style?

Because the CSS rules that define sticky only defines when something gets stuck, not that it's stuck. Ergo, it can say "this element becomes stuck when it's containing element is 200px from the top edge of the viewport", but until the user actually scrolls the document so that's true, the CSS rules that defined that doesn't make it stuck yet.

Personally, I'd settle for a pseudo class (e.g. `:stuck`, like `:active` I suppose). Currently I use an `IntersectionObserver` to dynamically toggle a `--stuck` class on my stickies, and I can target that as you describe it.

Then part of me feels like CSS shouldn't do the stuck thing at all. That's a job for scripting. There are unlimited behaviours like this you could try to account for declaratively but some JS will do it nicely. The thing about adding this to CSS is you are making CSS more complex with redraw loops as it needs to keep reconfiguring stuff as it gazes into thousands of it's own navels.

Ironic since the reason sticky exists was because developers were sick of managing it in JS. If you truly believe doing it in JS is better, feel free to do it in JS. No one is stopping you.

Pseudoclass seems like the obvious answer here but maybe there's a reason that's undesirable that I'm not familiar with.

I wonder if the idea is that adding pseudo-classes for the different things is not really scalable because you would ultimately need to do it for a lot of things -- requiring browsers to implement, test, and maintain custom code for each selector -- and you cannot anticipate every website's needs.

That would be a better framing for this feature. Given that framing, I can now see how it could be useful for things like custom controls not present in the set provided by the browser.

It would be interesting to see if browsers could use this mechanism internally to implement pseudo-classes.

I've been on a LOS since v18 on a Samsung device, and — barring a handful of inconveniences — I love it. (Most) things just work and I'm confident they will keep on working for a good while. Hardware will probably fail earlier than it losing software and update support.

That being said, I dread having to bump major versions on LOS, but I'm not sure if there's any getting around it. When I upgraded from v18 to v19, it was a massive chore to backup and restore what I had since the upgrade required a full flash, and that meant all data on my device is goong to be wiped. Now there's an outstanding upgrade to v20 available for my device, and the only reason I've been putting it off is the data wipe and restore tedium.

Exactly what happened to me as well. In my case, I was (fortunately?) messaged by someone from Fly.io after asking around the community forum how to remedy the issue. I think the person I talked to was inferring that the system got tripped because I was using my own domain for my email address.

It's since been corrected, and I still have a handful of services running with them, but getting started with the platform definitely was a rougher experience than I was expecting it to be.

So they will regard any large company using their service as fraud? Insane

Large company? Literally every company I ever worked for, the smallest one were 5 people, had their own domain for emails. And they were not all in IT.

So we agree its insane to cut off every company with a domain? Good.

I don't know what merchant system they are using but I will say it is very common for them to have their own anti fraud detection and rejection on charges. Your specific case could be related to a huge list of possibilities (even many of them a rollup of many other interactions on other sites that happen to use the same merchant or foundational fraud data).

Thinking this is just because of a domain name is silly.

Also Fly.io -- You may want to clearly accept and manage trial issues (or at least a subset) via a support path. It seems silly to effectively bounce users with the impression that you have no support because they are not YET paying customers while in the trial phase.

That would be insane, yes. It isn’t the case, though. I signed up with my own domain just fine.

No, we don't flag accounts as high risk based on email domain.

as a counter-point, i use custom domain for email, and haven't had a problem with fly.

It may not be custom domain but rather self-hosted mail server.

That's worse. A self-hosted mail server implies a significant cost investment that probably wouldn't be required for ye olde hotmail account.