Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


Nefarious intent? This is Google. People should avoid Google like the plague.


Meh, there is so much telemetry pouring out of Chrome, if this wasn't already a capability of the people interpreting that data, I would be surprised.


Feel free to block updates and enjoy security vulnerabilities. Or better yet just build your own version if chromium


Or switch browsers.


> 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.


Right, but if I use none of their stack, it doesn't affect me.

There is a bifurcation of people who want to learn about the tech they use every day, and those that don't.

Those that don't can't be saved if they won't grab around for the life raft.

Rest of us still want to build PWAs.


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.


> active/away status

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 add an API to allow servers to request your contact information and creditworthiness?

You can just opt out if you're not comfortable with it.


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 first one is just Autofill. I already have that, why should I be scared of it?


That already exists. It's called auto-complete, and for plenty of users it knows everything necessary to make purchases.


Seems fine to me if it's opt-in just like the idle-detection API.


That API already exists, and you can't opt out of it. Every one of the credit reporting agencies provides some variant of it to banks, right now.

Somehow, we all sleep at night anyway.


> 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?


So after 20 minutes instead of logging you out the away status is set.

Not sure I understand your special case here.


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.


In this case the Chrome setting would also mark you as away. I'm not sure what your argument is.


"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).


That's a setting within the chat app/website. Always remain online vs make inactive after 20 minutes or 4 hours.


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'?


He shouldn't and the fault is with the chat app. Why doesn't his chat app have a setting that allows him to set his availibility?


That usecase could just as easily be solved through this novel concept called "manual override".


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.


No web page needs this feature. If we think they do then we’ve missed the turn off somewhere. A web page is for consumption and not being spied on.


Yeah, explicit confirmation is nice.

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...


Or "productivity software" that queries browsers and use time. Sure, the employee could click 'no'...


> The example on web.dev is a chat app that would automatically set an active/away status: seems useful!

Okay, but you can already do that.


How? You need a native app gor that. A web app can only know whether a user is actiwe _on the webpage_


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.


> Every single feature on the web that gets misused has some useful applications too.

That's why you have the permission prompt.


> 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.

It really isn't. Some time look at the permissions controls in Chrome. https://twitter.com/dmitriid/status/1434086651362430976?s=20

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.


I don't understand what you're saying. It absolutely is behind a permission prompt. If you go to the demo site:

https://idle-detection.glitch.me/

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.


What I mean is that there is/will be a permission fatigue




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: