m0dest

This is ironically what’s become popular for service-specific usernames (“on twitter @dan” and “on instagram @danny”). It’s arguably more useful than the email notation because prefixing with the @ is a clear sign that a username is coming next.

Space bar handling in media players is a particularly hard problem because space bar is also the key that users expect to trigger the currently focused button. Some users rely entirely on keyboard focus.

So it starts to intersect with some non-obvious accessibility issues.

A blog post announcing version 1.0 is a good opportunity for a one-liner to explain what the heck your project is :) Just in case your audience happens to be expanding instead of contracting...

Bot detection seems like one of the more defensible uses of fingerprinting, and it might become a casualty in this war. If automated bot detection becomes impractical, the consequences are pretty negative for users: frequent captchas, login walls, aggressive throttling, mandatory email/SMS validations, and reduced accessibility.

Some may suggest that web services should just give up on bot detection, open up all of their private APIs, and accept bots and third-party clients as facts of life. But this idealism is out of touch with the reality of running an expensive, large-scale web service and a customer-facing business.

I've really loved Reddit's new design. It's very clean and focused. I found their old design to be cluttered and give too much emphasis to clickbait titles over actual content. I frankly wasn't really interested in Reddit until the redesign.

The combination of video streaming, bring-your-own-hardware, and closed source is just really difficult to get right. For every customer who has a good experience, there are three others who have some kind of persistent issue. There's just no way to deliver appliance-like reliability for a video server without controlling the hardware and OS.

The actual title of the article is "UniFi-Video Products End of Life Announcement". That's very different from this headline. Ubiquiti is very much still in the video business. They're just deprecating the previous generation, which has been a long time coming.

Note that they were bought by Akamai last year. I wouldn't count on the Krypton apps staying around, at least not in their current incarnation. A fork could survive, though.

HEIC (HEVC-based image) and AVIF (AV1-based image) both support a lossless mode that does efficient compression of blurs and gradients, without losing any visual fidelity. They're good candidates for screenshots in the future. Lossless HEIC is often 50% of the size of the equivalent PNG.

Part of it is about quality. These new formats now support 10+ bit color depth (which is critical for modern displays and for HDR) and full 4:4:4 chroma subsampling (to preserve pixel-level as needed). Many apps/services are currently evaluating or already migrating to AVIF or HEIC because these formats unlock those improvements in image quality, even without a major reduction in file size.

BPG came before HEIF. It was a great proof of concept, but there’s little reason for it to exist now. BPG was an impressive one-man spec; HEIF is based on input from OS developers, camera makers, IC designers, display manufacturers, etc.

HEIF is just a generic image container format. It’s almost identical in structure to a .mp4/.mov/.av1 file (follows ISO BMFF) and can be parsed in an identical way using a simple tree structure. That’s a perfect fit for wrapping a single video I-frame as an image, the basis of all of these new image codecs.

Note that video I-frames can often only be properly rendered using metadata from outside the bitstream, such as HDR characteristics, color profile, or orientation. Sharing that metadata structure with the codec’s canonical video format is the only way to be forward-compatible.

A HEIF that wraps AV1 frame(s) is an .avif

A HEIF that wraps HEVC frame(s) is a .heic

Codecs will change, but the HEIF container is probably the last bitmap file format that we’re going to need for decades.

Only native apps that explicitly opt-in to HEIC support.

When Google was working on the first Chromebook, they decided to give away some prototype Chromebooks to developers for free. There was a web form to request one. A small portion of the requests were granted.

But they also took a more targeted approach: If you appeared to be a frequent user of the Dev release channel of Chrome (unstable), an offer would appear on the New Tab page to immediately claim a prototype Chromebook for free.

I only know this because that’s how I got mine. A coworker of mine was interested in developing a ChromeOS app, tried switching to the Chrome Dev channel like me, and received a similar offer in a few days.

It was great targeting. We both ended up making ChromeOS-specific improvements to a popular web app. When you compare this to the cost of paying a company to port their app to your platform, this was a good deal for them.

One aspect of "lightness" is transfer & disk: initial download duration, storage size per app (often over 100 MB for apps with embedded Chromium), and the size of each app update which often needs to update the embedded Chromium too, if they're being responsible. There is no "LTS" version of Chromium.

For better or for worse, WebRTC is very opinionated about codecs and transports. Those might be great choices for some scenarios, but no developer wants their whole business to be constrained it.

Exactly this.

I worked on the design and rollout of multiple sign in providers on a popular app. There are best practices that avoid these issues (users forgetting which service they used), but they are rarely implemented.

The trick is to be very forgiving: If a user tries to sign in using provider X, and we discover an email address conflict with an account that uses provider Y, we would simply ask users to confirm by clicking a button to sign in with provider Y. From that point forward, both provider X and provider Y can be used to sign into the account.

So many apps miss the importance of this and cut corners by only allowing an account to be associated with 1 sign-in provider, or forcing users to create passwords for these accounts, or differentiating between login and signup.

Short term, I suspect that it’s going to be more relevant for porting functionality to iPadOS and/or allowing that functionality to be shared between Mac and iPad (in Catalyst apps).

Great point. I’ll have to dream up another dystopian fate for SSH.

It’d probably be some new PKI on top of SSH where your private key would be held in escrow by an identity provider. e.g. Your username is your email address, and your email provider retains your key pair. It’d probably be portrayed as an improved key management solution that allows more frequent key rotations and revocations. Might even start with being required for government projects, resulting in supported implementations by cloud providers that want lucrative government contracts. Then they just wait for a crisis opportunity like a cyberattack to force ISPs to block non-PKI-based SSH traffic in the name of national security.

And the largest and most paranoid companies that host their own mail and authentication services on-perm would probably be allowed to use those. But most everyone else is left doing key escrow with Google and O365 for their work and personal accounts...

Exactly. If you’re telling them that you’ve already made a decision not to convert to a paid user, then your trial evaluation is already complete. If you’d like to string them along until the last minute, that’s your prerogative, but don’t expect them to make it easy for you.

That being said, this “1 year free trial” of Apple TV+ is fairly ludicrous. It’s more like a public beta because they know that the service doesn’t yet have enough content to justify its cost, and the promo users are helping them create the perception of a popular service.

Unless I’m missing something, RFC7710 doesn’t offer anything to address this “tiered” captive portal scenario; it just provides a less vendor-dependent protocol for the captive portal checks that are already being performed by the OS.

If you’re using a mainstream OS that automatically detects standard captive portals, the main reason why you’ll need this is for “tiered” captive portals like the ones offered on some airplanes.

Those tiered captive portals have unique requirements that conflict with OS behavior:

A) By default, they want to offer some limited Internet access, such as accessing a sponsored site (often a shopping site like Amazon) or streaming videos (from some server on the airplane LAN).

B) For premium, paying users, they want to offer (mostly) full Internet access

For this to work, they have to fool devices in Tier A into believing that they have Internet access, by spoofing responses from standard captive portal detection URLs like captive.apple.com. Otherwise, if the network fails the captive portal test, many devices won’t stay connected to the Wi-Fi network, preventing access to the sponsored sites or LAN streaming apps.

At the same time, they want users to be able to upgrade from Tier A (limited access) to Tier B (full access) at any time. So they enable these upgrades by serving a captive portal page... to every HTTP site _except_ the standard OS captive portal detection pages that would affect OS behavior.

That’s when the user needs to visit an HTTP site other than the standard captive portal pages. One like neverssl.com

It’s obviously a fragile solution and is becoming an increasingly poor experience as sites adopt HTTPS, HSTS, and other standards. At the same time, I don’t know of any upcoming solutions to the tiered captive portal problem. Does anyone know what should replace this?

I’ve used http://www.fake.com for years just because it worked. If that London-based artificial plant company ever goes out of business, I don’t know what I’ll do! ;)

I think you just reinvented Airbnb Plus

https://www.airbnb.com/plus

I get where you're coming from. I was around then too. :)

Then this happened:

https://trends.google.com/trends/explore?date=all&q=sticky%2...

The popular usage of "sticky headers" had the opposite meaning of "sticky" compared to "sticky footers." The usage of this word to refer to the header behavior won out and was formalized as position:sticky in CSS3 Layout.

The problem now is when people use "sticky footer" in the former sense, it's misinterpreted. Note the other comments on this story.

Thanks for sharing this. Some folks are still using JavaScript for this, and it's unnecessary.

One nit: This isn't a "sticky" footer, and that's a good thing. I'd just call this a "bottom footer" for lack of a better term.

Sticky is used to describe an element that starts with a non-fixed (non-overlaying) position such as position:static and switches to a fixed (overlaying) position to stay visible on screen during scrolling.

https://developer.mozilla.org/en-US/docs/Web/CSS/position#st...

This is: The footer is placed at the bottom of the window or the bottom of the body, whichever is _lower_.

Sticky would be: The footer is placed at the bottom of the window or the bottom of the body, whichever is _higher_.

Mods, please fix the post title. The idea of a backdoor is speculation that is not substantiated by the article.

"will be forced to share users’ encrypted messages with British police"

So far, all the article is saying is that ciphertext will have to be shared.

Agree. The title of this post is dangerously deceptive and should be changed. The linked source does not claim or substantiate any backdoor.

>"will be forced to share users’ encrypted messages with British police"

So far, all the article is saying is that ciphertext will have to be shared. Anything about decrypted messages is speculation at this point.

(It would be very bad if a backdoor will be forced.)

I'd been trying to figure out why they required a user interaction for some of these. 5 out of 6 of these can be explained by debouncing.

• "Wi-Fi" and "Bluetooth" connection triggers are extremely susceptible to bouncing on and off with variable radio conditions

• "Arrive", "Leave", and "Before I Leave" are all susceptible to bouncing in and out; they combine a fuzzy location of variable precision with a point and radius

By requiring a user interaction, it makes sure that bouncing never causes the shortcut to trigger more often than desired. Apple certainly tries to debounce the event automatically, but that comes with other side effects: the trigger can be delayed significantly and unpredictably.

(As for why "Time of Day" requires a user interaction, I have yet to hear a satisfying explanation. I want my Cron!)