I am a privacy-conscious person but I really wish these debates could be a little more nuanced.
This API is behind a permission prompt that can only be triggered in response to a user gesture, so the bar to entry is high. The example on web.dev is a chat app that would automatically set an active/away status: seems useful! IMO I ought to have the ability to cash in some of my privacy chips (so to speak) on a site that I know and trust and that I want extra functionality from.
Relatedly, I feel like Safari is heavy-handed in the opposite direction. For example, it removes all locally stored data from a site if it isn't used within 7 days. There are sites I use less frequently than that where I'd still appreciate the ability to save information, but I don't have a choice. It all but guarantees sites need logins, backend storage etc. just to store simple data, which ends up being just as big a privacy danger!
The privacy problem isn't that Chrome is offering this permission to websites, it's that they built it into the browser at all. Now their browser, regardless of whether you're using any websites with this permission granted or not, has code that tracks if you're idle or not.
There's no bar of entry whatsoever for this. Chrome will automatically update itself to Chrome 94 and voila - it tracks your idle status. Worse yet is if you try to complain, they can shift the conversation by saying the ability is there for websites behind a permission dialog, and of course they take user privacy seriously. Basically exactly what you've done!
I don't think it's paranoid to assume nefarious intent because web devs weren't asking for this functionality nor was it impossible before. You add a mouse listener to the page, you check document.hidden, etc. With so many techniques already available ask yourself: why did Google spend time building this? And why didn't they consult other web stakeholders?
google’s catch phrase was something about not being evil, pretty sure that saying is bogus now and has been bogus for a long time. it really seems like they’ve been siding with some highly questionable practices and no official is gonna step in and check them, especially if a government can benefit by passing laws that force google to hand over the keys/info. it’s kinda sick how much we are engulfed with this stuff lately
If the feature only tracks idleness when the user has been appropriately asked, then why care? It sounds like you're just worried instead by a potential future version that works with a completely different permission model and use-case. I don't think that's any more useful to worry about than "what if Google decides to just send someone a virus with their auto updates?" (well ok, maybe that's kind of interesting to worry about but it's not especially related to this API).
>I don't think it's paranoid to assume nefarious intent because web devs weren't asking for this functionality
I use chat webapps occasionally like Discord and it would be very useful there. Right now I usually use the desktop application which is basically a wrapper around the web app with a few more abilities like idleness tracking. It would be nice if the web app could have that functionality so I don't have to run an unsandboxed executable on my computer with access to all my files just for it.
>nor was it impossible before. You add a mouse listener to the page, you check document.hidden, etc.
That only tracks idleness within the current tab, not the whole device. For chat applications that difference is important.
I think you missed my main point which is that for a browser to offer a permission-gated flow to website developers, the browser executable itself needs to have the idle detection system in place. There's no permission to turn _that_ off in the browser itself. It can track your lock screen, and activity outside the browser without prompting you. It's installed automatically by the auto update mechanism.
You could argue that Chrome was already doing this and sending that data back to Google over telemetry. (I don't know if they were.) That's where my second point comes in. Before, they had no justification for this. If they do it, it would look like creepy tracking. Now if you call attention to it they can say oh that's just there to power idleness API, nothing to worry about.
> The example on web.dev is a chat app that would automatically set an active/away status: seems useful!
That's exactly how Google uses it. They will make an interesting feature, that absolutely require this to be enabled.
It's similar to how to get list of recently watched YouTube video on your phone you need to give permission to Google to log your history, because it's impossible, of course, to store that locally on your phone.
You talk like that because you're a front web developer and that's your bread and butter. There are tons of other areas (even in computer science) where you are out of your bubble and you know nothing about.
Similarly, there are people who don't work on websites, writing javascript, in fact they think they think those people are dumb monkeys who can't even make their stuff work on all browsers.
They don't care about latest features, in fact they prefer browser being a dumb tool to view websites not a replacement for an OS.
This can easily be abused for stalkerish behavior. Even read receipts in chat apps like Facebook should be able to be disabled by the user. (You can, with some JS injection, but basically that means programmers' privacy is respected and non-programmers' privacy is violated.)
Also micromanagement.
I once had a coworker who would "pounce" on me when my Slack status became active, instead of respecting the time I needed to code. I had to set my Slack status to always away.
Yeah, nobody wants presence features. I think it's especially annoying on Discord, because nobody cares which anonymous subset of 1000 users is currently sleeping or awake or has their screensaver going. Most of my friends type at me while they're "offline". Uh huh. (The reason is "I'm avoiding someone", which indicates that the feature is only for evil.)
Slack isn't as bothersome (it doesn't seem to try to detect "stepped away from the computer for 5 minutes", it's just "closed the app for the day" or "has the app open", which is better than Discord), but it's a feature that should totally go away.
Slack's "z" indicator for "outside of work hours" is fine. I will note the irony behind switching to Slack only to have Slackbot send them a "electronic mail" when they get back online ;) If only there was some other system that could send messages to users and have them read them when they feel like it.
> This can easily be abused for stalkerish behavior
Well, sure. Any away/active status can be used for bad things. Pretty much any form of text communication can, too. We all opt in and out of things according to our level of comfort, like with the permission prompt this API provides.
Until you're required to accept the permission to keep your job. Tracking users to this level, even if you're paying them for work, is bad and will be abused. Is it handy? Sure. But maybe we all need to consider if we actually need to know the status of other people so much.
Why not debate the API that’s in front of us rather than make up excessive imaginary ones?
(besides, payment APIs are already able to request your contact information in order to bill you and ship things to you. And guess what: pretty useful!)
> The example on web.dev is a chat app that would automatically set an active/away status: seems useful!
I have an alternative way to do this. Check if a user hasn't interacted with your text box in x period of time. If they haven't, set them to away.
I'm sure people can come up with other methods too. It just seems like there's a thousand ways to skin this cat that don't have the same potential for privacy issues.
But this isn't adequate for the IM use case at all? I spend the bulk of my time not focused on my chat app tab(s) but I definitely want to be reported as 'available' by those chat apps, because I am if someone messages me.
If I am using a chat app, I definitely have no interest to tell you anything outside of the chat window. Why on the earth should I tell everyone that I am in front of the computer or not? Can't they just tell if I use the chat app recently or not? (It's public info anyway, if i am chatting in group, others will see the message.) Such function is definitely a security risk and I don't think I need it.
Even only with public group messages, you can figure out some others sleep schedule or when is he/she mostly active if you have enough data. This api will only make things worse because it trace you 'actively' now.
Besides that, you are able to send message when other is not here is the biggest point of a text chat app. If you must chat instantly, why not just call with phone?
Can't speak for the other commenter, but I'm "available" when I sit at my computer playing Civilization for 6 hours, despite the fact that I won't touch my IM application that entire time. If you're trying to set "Away" based on how often I interact with the application, you're getting it wrong for 5 hours and 40 minutes of that period.
"It’s not just about your usage of Chrome or a particular website: If you’ve stepped away from your computer and aren’t using any applications, Chrome can tell the website you’re not actively using your computer."
That suggests to me that this feature is more than just "did you touch that particular tab", and I'm not really sure how you're reading it differently?
I don't see what's not to understand or what logging out has to do with it. I have a browser tab for an IM application, that's also available as a native app on my phone. That tab is always open on my desktop. If I have other tabs open and am doing stuff, I still want my IM status to be 'available', and I want all notifications about new chats to go to that tab and to no other devices, while I am on my computer doing stuff.
If I go out for a walk or I go watch some TV or otherwise stop using my computer, depending on the chat app I want to either automatically be 'unavailable' (for work chat app), or I want to stay 'available' but have notifications go to my phone instead of the chat tab (for friends' chat apps).
His "special case" is that he goes more than 20 minutes between checking his chat client, but he is still available, so why should he be marked as 'away'?
Or you could manually message each of your contacts to let them know when you are available. Or you could physically show up at people's houses to let them know that you are available to talk.
There is always a less convenient and more manual way. Pointing that out helps no one.
However this is assuming Chrome won't have a whitelist of favoured domains that can bypass permission prompts like it has for other features (audio auto-play, and I believe also some VR-functionality, probably other things on top since I last checked). I gave the linked pages a quick look but it looks like the feature is still being worked on, and...I'm too tired to look through draft spec documents right now...
The point of an active/away indicator is to indicate whether the recipient of a message is likely to see/respond to the message in real time. If I'm active in another website and have notifications disabled I might not see it.
> The example on web.dev is a chat app that would automatically set an active/away status: seems useful!
Every single feature on the web that gets misused has some useful applications too. For me, the useful applications hardly ever outweigh the downsides. The web has been getting progressively worse and worse.
Most of these toggles will pop up a permissions dialog. Trigger enough of those, and the user will either dismiss them automatically or accept automatically.
and click "ephemeral", it shows a prompt next to the address bar saying "idle-detection.glitch.me wants to know when you're actively using this device" and has buttons for "block" and "allow". So I don't know how "it really isn't" could be true in this case.
"As you might expect, developers love this new feature—anything that can provide them with more information regarding how users are interacting with their apps is a positive."
Here I am deliberately designing apps that track no user interaction data at all. Maybe that's why Google doesn't even list my app even though it's one of the longest running "web apps" alive and used to be listed #1 when it first came out. Now they have more ads for similar apps than search results on a search results page.
> Maybe that's why Google doesn't even list my app even though it's one of the longest running "web apps" alive
Is your hypothesis that Google would have some incentive that you collect user interaction data? Why would that be?
> used to be listed #1 when it first came out
Back in 2002. A lot has happened since then.
Your app [1] is not comparable to what competitors like Zoho offer. There's plenty of potential reasons for not being ranked higher: from the landing page, to the increase in SaaS competition, to not keeping up with UX trends etc.
Zoho is a fine app, but it's described as such "Zoho CRM is an online Sales CRM software that manages your sales,.."
That's not what ezInvoice does. There is a lot of crossover in the features we offer, but they're not really the same.
As to keeping up, the ezInvoice app is a Cloud app, and it's also a "Single Page", Offline-First, and Local-First app, so you're either missing that or ignoring it.
>> Is your hypothesis that Google would have some incentive that you collect user interaction data? Why would that be?
Goggle is in the business of collecting as much data on users as they can, and that includes the users of the products advertised on their platform and those companies that place them. They offer services specifically for that purpose and as far as I know Google sells data to other corporations.
I already don't really like how websites can detect whether a tab is active or not (perhaps because callbacks/timers get delayed when a tab is inactive?). For example, dslreports's speedtest fails your measurement if you switch tabs, and Duo's web 2FA interface fails to approve a device which you've set to remember for 30 days if you're in a different tab.
You know who loves to use this feature? Recaptcha!
When browsing Firefox in Incognito mode with uBlock Origin and uMatrix fully active, the Recaptcha challenges load painfully slowly. Like each picture might take upwards of five seconds to refresh.
And to my delight, I have noticed that if I flip away from that tab while the panels are refreshing, they pause until I bring the tab back into active focus.
It's a slap in the face that this kind of user-hostile design is allowed.
When I log into my account, it starts up some react or angular type bullcrap that takes literally 5-10 seconds to fully load no matter what computer I'm on or what browser I'm in. If I switch away to another tab to do something else while it's doing that, _it will never fully load_. The only option is to sit there with the tab open and stare at it until my account information appears.
In 2021, I guess I should just be happy that they're not showing me ad while wasting my time.
Do you have a clue of how to prevent or disable the active/focus/blur tab events as an end-user? Like going to uBlock Origin route or something? There is one portal that heavily used this event calls and I don’t mind. The issue if I want to generate a report or sending queries/message, I have to be on that tab for them to process it. They often take 10 seconds to 1 min to process it. If I leave the tab, I have to restart the process again. It is disruptive to my workflow since I have to be on that tab for it to do something. I wonder if there is a way to generate a fake/mock event to fool the portal that the tab is active while I am looking in another tab?
There are a few ways to do it. First is document.hidden but that's the simplest monkey patch ever. Pass through iframe can detect some monkey patches though. visibilitychange too.
you're right! at least before it was somewhat mitigated I think?, you can measure timing Chrome used to slow down inactive tabs with rounded ms I believe I'd have to check the fingerprinting JS i wrote a few years ago.
Mouse movement is a good one too.
I'm sure there are other hacks maybe onfocus the entire window and poll it.
IntersectionObserver sounds like a good thread, there is a good polyfill library too.
I find the page visibility API, supported by every browser including Firefox, just as creepy. Perhaps even more, since most users don't know it exists and gave no permission for it to operate. Websites have no business knowing if I'm looking at them or not, and making assumptions about what I want them to do when I'm not.
Interesting that the minimum threshold is one minute. That might be too long for features like auto-saving documents, but lower-precision probably avoids a lot of nasty use cases too.
There's two reasons why I think it's a bad idea, along with a number of other Chrome APIs:
1. Most people aren't engineers and don't understand the privacy implications of this, and these types of metadata collections. Browsers aren't just developer tools, they are made for the general public.
2. I already get spammed by too many permission popups; rarely are they for purposes that benefit the user. It would be interested to see some stats on how many users simply accept these popups to dismiss them without regard for the consequences.
"Sorry! Looks like something went wrong. In order to use our site you'll have to enable idle tracking. This helps us improve our software for customers like you!"
If you’re saying the feature is only OK as long as at least one major browser doesn’t implement it, to prevent it getting traction, I don’t think it’s a good feature.
Because if there's a facility that grants out-of-browser data to the remote, the remote can deny service unless it is enabled.
Unless the feature is designed to fake data and make permission status opaque to the remote, it's a privacy reduction that will happen, the only question is when.
It’ll find a workaround that causes you to be asked permission constantly so you’ll give in and accept it. Web pages will do anything to manipulate APIs in nefarious utilization.
Students last year were complaining about Respondus, and it’s privacy invasive nature, now chrome supports features similar to it. In response to this my school allowed teachers to give easier tests to students using Respondus since they could be sure they weren’t cheating and allowed more complicated tests to be made for those refusing to use Respondus. Maybe with this they’ll recommend chrome and allow a medium difficultly test to be provided to those students.
Usually the W3C spec for new features like this will contain a few paragraphs outlining intended use cases.
In this case:
> Making these distinctions is important for applications which have the option of delivering notifications across multiple devices, such as a desktop and smartphone. Users may find it frustrating when notifications are delivered to the wrong device or are disruptive. For example, if they switch from a tab containing a messaging application to one for a document they are editing, the messaging application, not being able to observe that the user is still interacting with their device, may assume that they have left to grab a coffee and start delivering notifications to their phone, causing it to buzz distractingly, instead of displaying notifications on their desktop or incrementing a badge count.
> the messaging application, not being able to observe that the user is still interacting with their device, may assume that they have left to grab a coffee and start delivering notifications to their phone, causing it to buzz distractingly, instead of displaying notifications on their desktop or incrementing a badge count.
Is any webapp doing this? To me it sounds like multiple steps into the future:
- First a webapp has to have the capability to notify just one device, so in this case your browser and not also your phone. I cant think of an app where you dont receive double notifications on web+mobile (or triple with a smartwatch).
- The webapp then needs to be smart enough to dynamically select the "most active" device to send the notification to.
- The new feature can then be used as a workaround for "incorrectly" classifying your computer as an inactive device, because you are not interacting with the webpage anymore.
An opt-in system to allow idle detection is an explicit control. It shouldn't be the only option, but denying that it should be an option at all feels a little infantilizing.
my point, that you glossed over, can be illustrated this way: I want my phone to have GPS so I can use it to figure out where I am, for mapping, etc. I don't want it used for spying on me.
An opt-in system to allow GPS (or idle detection) is an explicit control, but it is not toggling the usage of this low level feature, which is the important part that I want to approve. Approvals should not be blanket.
If the permission system is truly the same setup as microphone and camera access, that includes asking for permission on every new access session and an easy location on the menu bar to revoke permissions again.
It detects whether the user is using the computer, not just the tab. If they were using another program for a prolonged period it would still report them as active.
Think about it: if a device's gyroscope is left idle, it presumes the behavior of a virtual machine. I imagine trust scores use this as a metric when deciding if the user is human or a machine: `device was left in the same geo-coords for a long period of time`: then it is a bot.
Hmm, they used to have drop sensors, at least! Or did those go out of fashion with spinning disks?
ISTR the motion sensing web APIs worked on Mac laptops when they were originally added (then later stopped working, either intentionally or through neglect).
I think the real story here is that the browser has really become the OS. But whereas before we left all decisions up to the users about what they could install and trust, and they trusted the dev to not do anything nefarious, the browser makers realized that users are a bad judge of character and devs cannot be trusted to be honest. So the browsers created a complex api access process to protect users from bad actors.
To move this sort of paradigm back into OS would require a wholesale re-write of APIs and how they're accessed.
Surprise! Both Apple and Microsoft did that, but neither of their new APIs caught on, because the benefit of being a native app was outshined by losing the easy access to the user data. So from the dev's stand point they may as well get the benefits of cross platform that web-apps afford if they're gonna have to deal with the gate-keeping anyways; native performance be damned.
Or just no mouse or keyboard activity for a while — because if the latter, my website could already know that.
We built an app for distance learning which put something a lot more invasive (but with permission)… namely eye tracking and facial recognition to see whether the kids are paying attention. It’s actually LESS invasive than the current alternative — requiring the kid to keep their camera on. Now the teacher jusy knows when the kid is present and when not.
Frankly, USA public schooling is about as invasive and controlling for kids as schooling can get. Every minute of their lives inside the school is regimented. So distance learning can be a respite.
Says the company which has no intent whatsoever of providing a half decent alternative to Chrome.
Instead of designing a system that allows third parties to offer alternative browsers they decided to be selfish and do everything by themselves for themselves, and wonder why their market share continues to plummet.
Where is the GeckoView alernative for desktops that would allow their technology further reach?
I've used Firefox for over a decade and a half and haven't ever had a use breaking issue where I felt the need to switch. Where are you getting this idea it's not a viable alternative?
More likely their share is smaller because they're competing against one of the largest companies in the world.
Yeah, I'm genuinely puzzled as to where these commenters are coming from. FF is a fantastic product and I have it installed all my devices after moving away from Chrome and Google products. I also managed to convince our IT to ship it as default on all of our company PCs.
I use both. As an end user the difference is fairly minimal. As dev maybe the debugger is a bit nicer in chrome, but that is just opinion. Also for me in some cases chrome is becoming the new 'IE'. The site will only work in chrome. For my wife if I switched out firefox for chrome I doubt she would even notice.
Imagine if Mozilla spent even one tenth the amount of effort on their own crappy product as they do hand-wringing about Chrome. We might have another viable web browser.
The quote the article is based around is discussing a new web API in the context of deciding what Mozilla thinks about it. If Mozilla isn't going to have any opinions on new web APIs, then what is even the point of Firefox? (Disclaimer, I work on Firefox but I know anything about specs.)
This API is behind a permission prompt that can only be triggered in response to a user gesture, so the bar to entry is high. The example on web.dev is a chat app that would automatically set an active/away status: seems useful! IMO I ought to have the ability to cash in some of my privacy chips (so to speak) on a site that I know and trust and that I want extra functionality from.
Relatedly, I feel like Safari is heavy-handed in the opposite direction. For example, it removes all locally stored data from a site if it isn't used within 7 days. There are sites I use less frequently than that where I'd still appreciate the ability to save information, but I don't have a choice. It all but guarantees sites need logins, backend storage etc. just to store simple data, which ends up being just as big a privacy danger!