7 ms·
This is what I was just thinking. It asks for permission just like microphone or location. Both of which you could argue 'allow for surveillance'
by vorticalbox 5y ago
This is what I was just thinking. It asks for permission just like microphone or location.
Both of which you could argue 'allow for surveillance'
- throwawaynew23 5y agoStudents 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.
- detaro 5y agoThat's... not a good thing.
- josteink 5y agoThose permissions have pretty clear use-cases which benefits the user itself and enables things which otherwise wouldn’t be possible. What user-oriented use-cases does this enable which couldn’t have been done otherwise? I really thinks this is apples vs oranges.
- phnofive 5y agoAbsolutely - and I think the typical user has long since been conditioned to click 'Yes' without reading.
- Ajedi32 5y agoUsually 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. Source: https://wicg.github.io/idle-detection/#introduction https://wicg.github.io/idle-detection/#introduction
- cdirkx 5y ago> 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.
- fsckboy 5y agogiving the users explicit control over where their messages are sent is a good idea. being spied on supposedly so the system can decide where to send you messages is a bad idea.
- Talanes 5y agoAn 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.
- fsckboy 5y agomy 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.
- Talanes 5y ago