Hacker News Reader

There are other ways to detect if a tab/window is in foreground. One hack is abusing timer slowdown (setInterval() resolution is moved to 1000ms for background tabs, you could compare against system time to detect this).

I've thought a lot about this api because I've recently both used it as a developer to reduce the resource intensity of my web app and as a user taking an online exam. The way I see it, all the uses where this is "tracking the user" would simply require the permission and all the ones where it's just an optimization would never be used because the permission adds friction.

Like, if I'm setting up an online exam and my requirement is that I need to know if the window is in focus, I won't let students who don't give that permission participate. And if the browsers don't inform me of the permission state and simply don't send the events, I'd scrap the project and force students to use locally installed proctoring software.

On the other hand, if I'm trying to save resources by suspending live updates and heavy rendering when a user tabs away, asking for a "track your activity" permission would cause a lot of friction and user loss (because even just asking for it sounds creepy). Very few users will notice the resource usage, or if they do, will think it's unavoidable, so I simply won't implement those optimisations.

Everybody loses.

You can't require permission if the default action is spoofing. This is how I think all privacy-related features should be implemented. If I don't want a website to use cookies, the browser shouldn't let the website know it can't. It should just pretend to let it use it, while forgetting the cookie when the browser is closed.

As a side note I think prompts like 'letting website track your identity' is misleading and infantilizing. Just let user know what is being accessed, like

- Do you want this website to know when you left the page? We won't let them know if you don't.

- Do you want to allow this website to save cookies? If you don't, all cookies from this site will be cleared when you close the browser.

At this point, we need to acknowledge that browsing the web safely is essentially an adversarial game against adtech and spyware companies. If we don't fight with all our might, we'll just lose. This isn't 2005 anymore. I too wish we could go back, but we can't.

Hard agree. The proper place for cookie permission management is in the browser. The web as a whole needs need to move on from these obnoxious pop-up cookie warnings ASAP.

> The web as a whole needs need to move on from these obnoxious pop-up cookie warnings ASAP.

Those obnoxious cookie pop-ups can go away today. No browser intervention necessary.

You know why? They only exist because the greedy industry really wants to collect and sell your private information at scale. No other reason. So the companies could remove those popups today if they cared.

If you move the dialog to the browser, you will have both the browser dialogs and the non-cookie dialogs (because they will still want to fingerprint you, and collect your data, and sell it)

And you could optimize the use of resources further if you knew the user wasn’t sitting at their desk but that doesn’t mean we should open up webcam APIs as permissionless.

It’s good that you’re using the API in a noble way, but many will not, so it should be up to the user and the settings of the browser they choose to optimize the use of their computer’s resources.

You optimize your system as best you can without spying on the user, and the rest is up to them.

The reason we don't do that is because of user privacy. Knowing whether a tab is shown or not has no impact on privacy. Should we add permissions for click events and mouse movements too?

>its use in various "ed tech" websites to detect alleged cheating[1] is frightening, to say the least

why is this frightening? proctoring software has long been used and is much more invasive than this, and the alternative is to simply not allow students to use their own devices, or even to take tests remotely - when i was in school the alternative to this sort of software was an exam proctor sitting behind you and watching your every move to make sure you didn't cheat. i get that outside of this sort of context it's bad, but that doesn't make it bad in the contexts where it actually is appropriate.

(In the case of Canvas) This is done surreptitiously without the student's knowledge. As far as I know, there is a separate lockdown proctoring browser which is for actual exams, but then there are some other quizzes which do not require using the locked down browser, but they nevertheless log a bunch of stuff that get sent to the instructor, who often may not know what they actually indicate and proceed to accuse students of cheating.

On your second point about the comparison of human proctor and this:

Lots of things are fine to do on a small scale, but becomes terribly invasive when you do it on a massive scale with the aid of computers. You may accept that the person driving behind you may take a note of your license plate, but would you say the same if someone installed a high resolution webcam on the pedestrian footbridge to see every single car that went through forever? The general issue with computer-assisted surveillance is that it is cheaply scalable and nearly impossible to erase.

Lastly, is there really a point in preventing the use of external information aids (textbooks, notes, Google) in an age where information is so widely available? Rote memorization has never been a good way to truly learn things, and maybe we should do away with this tradition of tests based on information reproduction.

Re: Your last point: If we test for understanding instead of facts, that is much more expensive to test for (as it cannot be automated... yet).

On top of that, cheating is still possible with readily available tools, even today! (For example, that one AI that shall not be named ;)

I don't follow why you are so opposed to the visibility api. I agree that it's annoying if used to ensure that I watch a certain video, but besides from that it doesn't seem malicious to me.

>they nevertheless log a bunch of stuff that get sent to the instructor

..what sort of stuff? And how is it related to the visibility api?

> I don't follow why you are so opposed to the visibility api.

It's in the second sentence.

  The ability for a website to see when you click on things outside of the page itself (either by changing active window or tab) is quite unexpected from an end-user perspective

> what sort of stuff? And how is it related to the visibility api?

It's in the linked article. At least a few of those events are implemented with the visibility api.

Good question. I've always assumed that when I take an exam online that I'm granting access to BOAT LOADS of PII (mouse movements, IP address, cookies, my video camera, my video camera as I point it around my room)

I've always chalked this up to "of course you need to be vigilant that I'm not cheating", but with the twist that I hold you to a high ethical bar with the data you collect about me.

Am I wrong to think about it this way?

Mind you, it's not just about the user explicitly inactivating the tab/window; the page visibility API also considers the page to be invisible if you completely cover the viewport by moving another window in front of said page's viewport. Or, for that matter, if the viewport is owned by an iframe, and that iframe is scrolled out of the bounds of its parent viewport.

The intention behind the Page Visibility API is supposed to be to allow the page to stop bothering to run JS intended solely to calculate DOM updates, if said DOM isn't currently being rendered where the user can see it. Like how "damage region"-based redraw event-pumping worked in native apps before window managers started doing compositing; or how culling works in 3D rendering. The browser asks the OS to notify it whenever the tab's viewport is entirely occluded; and when the browser receives said notification, it translates that to a Page Visibility API event for the tab.

And the annoying thing about that, is that an opt-in in this case would do away with all the subtle improvements to battery life that are the "correct" use-case of this API. It'd be like having to explicitly prompt the user to opt-in to allowing the use of WEBMs for displaying animations on pages, while allowing actual .GIF-file animations all the time. Websites that are just websites, not long-use apps, would know that users don't care enough to take the time to understand what's being asked and opt in to using extra APIs with them, so 80% of the time they'd get refused; so, for a "clean experience", they just wouldn't bother to ask, and would instead just consider the API verboten, and stick with doing the worse, more-CPU-intensive thing.

Meanwhile, the malicious use-cases would just ask; because for the malicious use-case, even just those 20% of users who naively default to "yes" to prompts instead of "no" would be enough to ensure they siphon off enough data to sell for sweet, sweet ad-tech dollars. (At least, that's how things seem to be for the similar Background Notification API.)

Effectively, you'd punish honest use-cases of the API (because the devs were only doing it out of the goodness of their hearts, and so a little thing like "80% of users won't benefit" is enough to make those devs not bother), while not really thwarting malicious use-cases (because they're highly incentivized.)

That would be a loss for sure, but I think the dangers of surveillance far outweighs the reduced CPU load from not rendering content sometimes. Wouldn't it be better to have the browser do this instead, by somehow ignoring the rendering when the tab is not visible?

As a side note, can you give a website where this is done? I feel like most modern websites are so bloated that no amount of these subtle optimizations would be better than just having a more minimalistic design, such as not fetching things continuously by default and doing away with unneeded animations.

> Wouldn't it be better to have the browser do this instead, by somehow ignoring the rendering when the tab is not visible?

The browser does already do this. Browsers are already smart enough to not "reflect" DOM updates to currently-hidden parts of the DOM into re-rendering passes. (Which is one reason a lot of people think "virtual DOM" frameworks are silly.)

What the Page Visibility API allows you to save the expense of, is running the JavaScript logic that translate into those DOM update calls. (Think: the logic that decides what horrible banner ad to fetch next, actually pre-fetches it, and then updates the DOM to tell the browser it's the ad that should be being displayed. Disabling that logic when the banner ad isn't visible => no more background network fetches for new ads.)

This requires an API, because the browser can't just be reaching into a Turing machine (i.e. some arbitrary Javascript program that could really be trying to do anything, given that webapps exist) and randomly shutting parts of it off. The browser needs a clear signal to hand that page-embedded Turing machine to say "if you have a part that's just for the sake of figuring out what to show next on the screen, then please stop running that part for now." That signal is a Page Visibility event.

(Though, this isn't the only way to accomplish that. If said Javascript program has provided a clear rendering API to the browser, that works too! I.e., if the page is pumping its logic using Window.requestAnimationFrame, then IIRC the browser can take as long as it likes to call the requestAnimationFrame callback back — and if the window is occluded, that would be a perfect time for the browser to wait on that. But if you think about it, "requestAnimationFrame taking longer to get called back" exposes basically the same data-leak that the Page Visibility API does, so...)

> As a side note, can you give a website where this is done?

YouTube, I believe, has independent video and audio streams, precisely so that whenever you leave the viewport occluded for a few seconds, it can stop bothering to fetch the video stream (or can drop the video stream down to the lowest resolution+bitrate version), while continuing to play the previous highest-negotiated-bitrate audio stream.

I agree. I've used Firefox extensions to override these APIs and stop sites like YouTube from pausing playback. The cheating detection thing in proctoring software is pretty disgusting as well.

These web sites are getting way too abusive with the powerful APIs we've given them. It's time to reassert control.

It is important to note that, reasserting control has to be done at a browser vendor level -- trying to spoof APIs with extensions or whatnot as I mentioned may be a good mitigation for a specific behavior, but it is often detectable in a way that makes it an excellent fingerprint.

I agree. The truth is many of these extensions should be built in browser features. Especially uBlock Origin.

The browser should be our user agent by default. Not some advertisement displaying, user snitching, corporate money making machine.

Unfortunately, a browser cannot realistically be controlled by a non-corporate-funded entity (if you don't count a government). Modern web browsers are incredibly complex and the web standards are made in a way that largely prevents the creation of new browsers. Firefox is mostly funded by Google, and Mozilla being the ineffective organization it is, this is unlikely to ever change.

https://drewdevault.com/2020/03/18/Reckless-limitless-scope....

Yes. The only reason why they shouldn't be features is the massive conflict of interest.

Brave is very much a thing.

Sorry, I meant to say browser engine

> Unfortunately, a browser cannot realistically be controlled by a non-corporate-funded entity (if you don't count a government).

Surely it can, we just need to make it happen. It's actual code that helps here, not nihilism.

To quote the wonderful ladybird project[0] (lead by a person who iirc worked on webkit too):

> Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff.

> Sure you can. Don’t listen to armchair defeatists who never worked on a browser.

[0]: https://awesomekling.github.io/Ladybird-a-new-cross-platform...

Andreas Kling made a browser too? That's incredible. He's an inspiration for me.

If you are using uBlockOrigin then you can block the visibilitychange event with this filter:

  *##+js(aeld, visibilitychange)

Just add it to `My filters`

Wow thanks. I'll try that when I can to avoid having random extensions inject scripts. How would you exclude a website for this if it doesn't work properly, especially with blur and focus?

Let's say you want to allow duckduckgo.com to listen to the visiblitychange event but all other sites should be blocked. Then you could use the following:

  ~duckduckgo.com,*##+js(aeld, visibilitychange)

There's also StopTheMadness which can prevent pages from using the visibility API and also removes a whole host of annoying behaviors from “modern” websites.

I know I probably already have most of those mitigations done, but, anything similar for non apple users?

I believe it has chrome and Firefox extensions as well

Another concerning web API is the Battery Status API. See demo[1]. Firefox and WebKit have not implemented it thankfully but Google refuses to remove it for some odd reason. How it ever came to be boggles me. A low-power API would make much more sense. The Battery Status API does not have a user facing toggle in Chrome, unlike the sensor APIs, let alone actual permissions. Speaking of which, I can't believe the Chrome team still hasn't done anything about the sensor APIs. I've turned it off and see so many analytics tools in websites try to use it. Another surprising browser API that's only in Chrome is the Network Information API - again, permissionless, and cannot be opted-out of.

A lot of the specs say that user agents must provide users with a way to disable support for certain API. CSP reporting is one that many uBO users will recognise. But of course, Google doesn't follow that. And many of the aforementioned APIs are not W3C standards and are merely working drafts.

[1] https://jsbin.com/battery-status-test/edit?html,output

I work in Ed tech and we have gotten requests from schools to implement anti-cheat methods along these lines. We’ve thus far declined.

At least in our case you’re largely only cheating yourself. Our whole goal is to meet you where you are so you can succeed. We level your options to your ability. By cheating, you’re just going to get presented with harder materials and make it harder for yourself than it already was.

It's almost trivial to do the same without this API: focus/blur events, user input from mouse/keyboard. A permission toggle will add nothing.

> its use in various "ed tech" websites to detect alleged cheating[1] is frightening, to say the least

Because? Monitoring what happens during an exam seems normal and reasonable. There is a limit to what is "reasonable" – monitoring webcam and microphone is not IMHO, but seeing if another tab was opened is fairly reasonable.

It's not during an exam. If you read the link referenced, it notes that Canvas can log activity even when in non-proctored tests, for which there is no indication or expectation of this happening. For proctored tests they just record with your webcam and microphone anyways.

It's still during an exam. The expectation of complete privacy of what happens on an exam webpage while you're taking the exam is an unreasonable expectation.

> The ability for a website to see when you click on things outside of the page itself

It doesn't let pages see what you're clicking on outside of the page. That would indeed be a serious privacy violation. It merely tells the page that it's not on-screen any more. Personally I don't see any problem with that.

The person you replied to literally posted an example of it being misused:

> The ability for a website to see when you click on things outside of the page itself (either by changing active window or tab) is quite unexpected from an end-user perspective, and its use in various "ed tech" websites to detect alleged cheating

I don't see how that's misuse.

If the "ed tech" site was detecting what you're doing 24/7, that would be a problem.

But for the 2 - 5 hour period of time that you're taking an exam and have their web page open, is it unreasonable?

Changing tab doesn't tell you where or what someone clicked on outside of the page itself though, only that the page is no longer visible.

I once used it (on a personal project) to add a sad-face emoji to the page’s <title> if the page wasn’t visible. It would change to a heart when they returned.

(Edit: since the emoji was prefixed, you could see it on the background tab)

Asking for permission increases user experience friction by a ton. Especially since Web permissions aren't all at once but page dependent.

Even something like asking for camera permission isn't obvious all the time. Tried to build a PWA with camera as the focus, but users weren't always aware of the cam permission. Sometimes it slightly bugged and the cam took a few seconds to load or didn't at all.