> Both experiences use the same Windows kernel system clock.
Ah yes, the lock screen experience. I could stare at it forever.
On a more serious note, does anyone know why they would do it like that? Why is one polling interval aligned and the other isn’t? What’s the security impact?
The security impact relates to the fundamental design architecture of the lock screen.
Similar to iOS Before First Unlock (BFU) security mechanisms being stronger and less capable overall, so too do you see this behavior on Windows.
The user mode lock screen is simply a full screen app, for which glitching the resolution of an “external” monitor which video out ports is often enough to desync the resolution of the full screen lock screen app and the full logged in user desktop behind it. IE: you can just… click past the lock screen app briefly running at a smaller resolution. As you might imagine, there’s a timing aspect to this.
I don’t really follow. Can you not get the time to the next minute flip and schedule the update 1s after that? How does the lock screen being different prevent that?
I’ve done clocks like this before. It was sheer laziness. Easier to just set a 30 second update window than to actually compute the time to next update. Particular in some of my sloppier projects without an event loop. Of course, the only person who saw the result was me and it made me chuckle at considering the complexity of managing time well.
> Both experiences use the same Windows kernel system clock.
Ah yes, the lock screen experience. I could stare at it forever.
On a more serious note, does anyone know why they would do it like that? Why is one polling interval aligned and the other isn’t? What’s the security impact?
The security impact relates to the fundamental design architecture of the lock screen.
Similar to iOS Before First Unlock (BFU) security mechanisms being stronger and less capable overall, so too do you see this behavior on Windows.
The user mode lock screen is simply a full screen app, for which glitching the resolution of an “external” monitor which video out ports is often enough to desync the resolution of the full screen lock screen app and the full logged in user desktop behind it. IE: you can just… click past the lock screen app briefly running at a smaller resolution. As you might imagine, there’s a timing aspect to this.
That’s why this behavior exists.
I don’t really follow. Can you not get the time to the next minute flip and schedule the update 1s after that? How does the lock screen being different prevent that?
I’ve done clocks like this before. It was sheer laziness. Easier to just set a 30 second update window than to actually compute the time to next update. Particular in some of my sloppier projects without an event loop. Of course, the only person who saw the result was me and it made me chuckle at considering the complexity of managing time well.