12 ms·

The other day I was scrolling past a panoramic picture on Facebook. I happened to jostle my phone, and was surprised to find I could look around the picture by

The other day I was scrolling past a panoramic picture on Facebook. I happened to jostle my phone, and was surprised to find I could look around the picture by tilting my phone. When the fsck did this become a feature? Why did nothing ask me if I was ok giving Facebook access to my hardware? How do I turn it off? Who thought this was a good idea!? These same questions apply to Bluetooth. Already, such a terrible standard when it comes to privacy. And now, random websites can grab control of my radios? With JavaScript? Nothing wrong can happen with this, for sure! FFS. This is like the battery api. Too much time spent on "can we", too little time spent on "should we".

andun 8y ago
All new web standars are a terrible idea to our privacy and security. And for some reason nobody seems to care.
- stevehawk 8y ago
  My theory on this is becoming - because the nerds that would care all work for the Big Five and as such think it's ok because "we're not evil". Once that crowd gets quieted then there's no on to raise the flags for others.
- deleted 8y ago
  [deleted]
- userbinator 8y ago
  People care, but those who do are not working on them and their voices get drowned out by the "push the web forward"/"progress is always good" crowd. I suppose there is a bit of cognitive dissonance among developers of such things too.
jake_the_third 8y ago
I run my(?) browsers in their own separate virtual machines. You loose copy and past and you'll need to set up folder sharing, but shit like this is a non-issue. No major browser vendor (and I mean not a single one) puts users' privacy first. People should treat browsers as the privacy hazard they are.
- vbezhenar 8y ago
  Why lose copy&paste? Virtualbox supports seamless copy&paste, every other VM probably supports it as well.
kgraves 8y ago
This is also similar to the time that WebUSB[1] was added to Chrome, allowing access to USB devices in the browser. I feel that we are frogs in boiling hot water. [1] https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web https://developers.google.com/web/updates/2016/03/access-usb...
chucky 8y ago
FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. In a wider sense, there are legitimate uses for many of these apis. To me it seems like the option would be that some phones would get these apis patched into the browser by the manufacturers instead, and that would run an even higher risk of security problems than when the browser vendors do it. If you don't like your browser application having access to certain hardware in your phone, you can just revoke the permission, and it won't have the access (at least on Android, I have no idea how iOS works in this regard).
- gsnedders 8y ago
  > FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.
  - earthscienceman 8y ago
    I still see FFOS as ahead of its time. I really wish it would have worked out better.There's all this jostelling happening between the role of software based apps vs. the role of web content/apps on devices... but in the end every day I see more and more content being served through the web. As browser integration improves (through things like 'web bluetooth') I think we're creeping more closely to the browser essentially being an app sandbox for your hardware/OS. Now, whether this is good or not is left as an exercise to the reader.
- tinus_hn 8y ago
  I think the original idea was that background JavaScript apps could suspend operations when your battery is running low. It quite an edge case but it’s one of those things that make a web app less than native.
koboll 8y ago
Right? Now imagine phone tilt or battery information on the scale of billions of people. Imagine what you can infer. This person's phone has been tilting less often over the past decade - a trend correlated with, let's say, a more strained gait caused by weight gain. The algorithm markets them more sugary foods, because there's a higher likelihood they're effectively addicted to calories. This other person is letting their battery run down more often - a trend correlated with undiagnosed depression. The algorithm ratchets up the fear and sadness because it infers these will be more effective motivators to buy products. The best part is that this will probably all happen invisibly. GDP and human suffering creeping up slowly, with no human at the helm, and the world none the wiser.
- obituary_latte 8y ago
  Also, when the phone is upside down (reading in bed), or traveling etc. Scary to think of all the things that could be gleaned.
- Brakenshire 8y ago
  Does phone tilt really give an acceloremeter data stream? I thought it was just landscape or portrait.
  - tokyodude 8y ago
    it does but only while the page is active. As soon as you switch tabs, apps, or your phone locks the data stops
lucideer 8y ago
The Web Bluetooth API asks you for permission every time. Like every new web standard like it. It's still something many users will blindly click through but at least there's that. At least this doesn't seem to be a priority feature for Mozilla yet. MDN doesn't even have proper docs for it. So I'm a bit thankful for that, for now. As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that.
- deleted 8y ago
  [deleted]
- bjt2n3904 8y ago
  How kind of them to ask! It has all the charm of someone walking up to my house at four in the morning, and knocking on the door to conduct a survey of which radio stations I listen to. It shouldn't be asking, ever. The answer is such a hard no, it makes me wonder why they even tried.
  - vbezhenar 8y ago
    Bluetooth provides useful features for many users, that's why.
    - bjt2n3904 8y ago
      Yes, like making poor estimates of my heart rate, being an insecure keyboard, or occasionally failing to deliver audio to my car speakers. Definitely will be useful in my web browser.
      - salvar 8y ago
        Are you claiming that Bluetooth can never be useful for anyone because you don't find it useful?
  - lucideer 8y ago
    Why specifically at four in the morning in your analogy? I mean, door-to-door surveys are a pretty common thing at normal hours of the day, and that seems like a reasonable analogy without the arbitrary time change.
realusername 8y ago
The battery api was removed from Firefox for this reason, it was only used for tracking unfortunately.
diggan 8y ago
> These same questions apply to Bluetooth. Already, such a terrible standard when it comes to privacy. And now, random websites can grab control of my radios? With JavaScript? Nothing wrong can happen with this, for sure! No, this is usually not how new features are being used in the browser (see geolocation). Websites won't be able to scan your nearby devices without asking for permission, and it's up to the user to accept/decline it. I'm actually quite excited over having Bluetooth accessible in the browser. That means that we could build P2P applications that works in the browser, that works even when not connected to a wifi and can talk with nearby computers via Bluetooth, something that has not been possible before (FlyWeb was close at achieving something like that as well)
- bjt2n3904 8y ago
  Because you know, I've always been on my desktop computer and said... "You know, I'd totally use that cool mesh Bluetooth chat app that's so popular and lets you communicate with people within a 25 yard radius, but ultimately falls back to using WiFi because Bluetooth is impractical for this application. Sadly it's not for desktops. If only I could use my web browser..." No! I've never said that! In fact, no one has ever said "I wish I could use Bluetooth in my browser", except for people who want to collect more data on their users. This is like an idea from Todd on Bojack Horseman. Again, too much time on "could we", not enough time on "should we". Bojack clip in question: https://youtu.be/Ct6EuC1W1gE https://youtu.be/Ct6EuC1W1gE
  - diggan 8y ago
    > In fact, no one has ever said "I wish I could use Bluetooth in my browser" I literally just wrote above that I do want that. I also don't care about collecting any data. Guess you have to take my word for that. So now you know one person at least :) I'm not sure where in the world you are, but there are many use cases where meshing clients together is the only way of getting non-restricted network access to each other. The only reason why I think Bluetooth + Browsers are a powerful combination is the fact that it's so easy for people to get started, compared to how desktop works. > I've always been on my desktop computer and said ... No! I've never said that! Great, maybe this is not for you but you should try to consider other peoples point of view as well, that might live on the other side of the planet. Otherwise discussing further becomes rather depressing.
Yaggo 8y ago
> [...] I could look around the picture by tilting my phone. When the fsck did this become a feature? Why did nothing ask me if I was ok giving Facebook access to my hardware? To be precice, by using the device orientation API offered by the browser, Facebook has no access to your hardware any more than it has access to your display hardware by utilizing the DOM API to draw on screen or access to your cellular radio by making a TCP connection. Whether the browser should require your permission (per site?) to use device orientation API, that's debatable. Anyway, that's up to the browser implementation.
- koolba 8y ago
  > Whether the browser should require your permission (per site?) to use device orientation API, that's debatable. Anyway, that's up to the browser implementation. I think anything that involves making new/more input available to remote sites should require opt in. At the very least it should have a toggle to disable it globally.
matt4077 8y ago
> Why did nothing ask me if I was ok giving Facebook access to my hardware? I'll let you in on a secret: Facebook is also controlling your graphics card, and CPU, and memory. Controlling as in "sending HTML that is then displayed via those hardware components". And just like a media query can "access" your device orientation, panoramic media can adapt to the data from accelerometers. The missing information here is the concept of "secure contexts": https://w3c.github.io/webappsec-secure-contexts/#intro https://w3c.github.io/webappsec-secure-contexts/#intro. Being able to use this data does not mean that it can be send back to the server.
- syn0byte 8y ago
  That's a misleading non-argument for the actual issue. "Your Wells Fargo bank accounts perfectly safe from bank employees because armored cars are used to transport money. They don't let normal bank employees into the back of those vehicles. Only licensed and bonded security guards are allowed."
- Ajedi32 8y ago
  "Secure Contexts" just means you're visiting the site over HTTPS. It has nothing to do with restricting the ability of JS to communicate with the internet.
simias 8y ago
>Too much time spent on "can we", too little time spent on "should we". I mean, that's the web summed up in a single sentence. What started as a way to view text and pictures online is now more complicated than many operating systems. You cram all that stuff into a single binary, give lackluster and ever changing controls to manage all that and call it the future. Never attempt to break down the functionality across several dedicated clients that do only one thing and do it well, that's for losers. But I somehow disagree with your statement in that it seems to imply that the people designing that garbage are naive or don't really think about the consequences of what they're doing. That might have been true in the early days of the web when nobody knew exactly what it was going to be but it's clearly not the case now. The folks at Google know exactly what they are doing, making browsers more complicated and easier to interconnect with smartphone is win/win for them. It makes it harder to make a competing browser (anybody attempting to make a new browser these days basically has to fork Chrome or Firefox, and generally they go with the former), you need huge developer resources to maintain and optimize it (look at how hard Firefox is struggling to keep up despite the large number of people working full time on it) and while the big G doesn't control Windows, Mac or Linux they do control Chrome and Android so they have a huge incentive to push everything possible away from desktop OSs and into Chrome. They want Chrome to be the OS. Google is 90's Microsoft with better PR. Well actually it's worse than that because MS didn't usually have access to my private data while google knows almost everything about their users if they have an Android phone and use gmail.
- UI_at_80x24 8y ago
  >Google is 90's Microsoft with better PR. Well actually it's worse than that because MS didn't usually have access to my private data while google knows almost everything about their users if they have an Android phone and use gmail This is the statement that I have known for years but never put into words. And it rings terrifyingly true.
  - dvfjsdhgfv 8y ago
    What is terrifying for me is that when it was happening - and it didn't happen overnight, it was a long process - relatively few people were objecting. The ones who objected were often ridiculed as the tinfoil-hat group. The people who should have been smart enough have been blinded by shiny new releases, the amazing things we can do now, for free. It's only recently that the general public started to discover the ugly truth, whereas we could clearly see it already many years ago!
deleted 8y ago
[deleted]
dtf 8y ago
If you're talking about the DeviceOrientation event [1], it's been shipping in browsers since 2010 [2,3]. It also works on your MacBook. [4] [1] https://w3c.github.io/deviceorientation/ https://w3c.github.io/deviceorientation/ [2] https://caniuse.com/#feat=deviceorientation https://caniuse.com/#feat=deviceorientation [3] https://www.engadget.com/2010/07/06/google-chrome-gets-some-early-device-orientation-plumbing/ https://www.engadget.com/2010/07/06/google-chrome-gets-some-... [4] https://simpl.info/deviceorientation/ https://simpl.info/deviceorientation/ (PS my humble opinion is "yes we should". I like being able to develop a heart rate monitor PWA for my phone, and I don't see what's different from granting some random native app the same access. At least with the web I can read the underlying code.)
- vardump 8y ago
  > It also works on your MacBook. [4] It did absolutely nothing on my 2015 MacBook (tried Safari, Chrome and Firefox). It does work on 2012 MacBook model on Google Chrome. I guess it only works on MacBook models that supported a mechanical disk — I think the sensor exists in the first place to protect spinning rust disks by parking the heads just before impact.
  - dtf 8y ago
    I just noticed that [4] doesn't work on Safari or Firefox either (but does on Chrome) on my MacBook 2010. Maybe it wasn't the best demo of that feature ... The API is pretty well supported on tablets and phones though, which is where the main use case is.
    - Fnoord 8y ago
      Doesn't do anything on my Chrome @ MBP 2015, but then again I use all kind of extensions.
grezql 8y ago
Another one is the Push Notifications in browsers. I always block them. Once you open up such APIs websites will abuse it no matter what.
kmlx 8y ago
hi. i develop webapps that run in the browser. these apps leverage webrtc, battery api, local/session storage, websocket, webvr/xr, webgl, you name it. all have legitimate purposes, all run in a browser under https and none have ever been used for tracking: one app that uses webrtc does one to many broadcasts, another uses webxr/webgl to display 3d vr experiences, etc. these apps are used by tens of thousands on a daily basis. and they’re nothing fancy. my advice is to not dismiss the advantages of the web just because of a few bad apples.
- falcolas 8y ago
  It's not a few bad apples. It's a shipping container full of rotten apples, and maybe two good ones. That is to say, without the analogy, that it's the ad companies who will abuse these, ruining virtually every web site that exists, and jading users against the technology for the few websites who aren't abusing it.
- laumars 8y ago
  > my advice is to not dismiss the advantages of the web just because of a few bad apples. Except protecting against the "few bad apples" is exactly what we're supposed to be doing. Eg you made a point that your use cases are all served over HTTPS - why should we be doing this when it adds complexity, adds bandwidth and breaks many legitimate corporate management tools? The reason we bother with TLS is precisely because of "a few bad apples". The point of security is to harden against those bad apples rather than ignore they exist just because developers want a shiny new toy to play with.
  - Ajedi32 8y ago
    Which is why the web has the most robust permissions system of any platform, period. Sites that need these features for legitimate purposes can access them, while sites that don't can't.
    - laumars 8y ago
      > Which is why the web has the most robust permissions system of any platform, period. I fundamentally disagree with that. Yes it has a permissions system but is it really all that robust? Let alone the most robust of any platform? First off you're dependant on the browser implementing that correctly (that's not always the case) and often there are thousand different ways you can still do naughty things even if those permissions are implemented correctly. Then there are the thousands of vulnerabilities built into the very design of the web that developers (of both web and browsers) are constantly having to code around (XSS, et al). And that's without even addressing the current problems we have with data leakage and privacy concerns that we seemingly have little control over at all. Compare that to networking where you have VLANs, subnets, firewalls and other network ACLs; or Linux servers where you have tools like SELinux. These tools might not be simple to use from the outset but their certainly a great deal more robust than any of the models the web has offered us thus far.
kinlan 8y ago
Site's can not do anything with Bluetooth API unless the user explicitly granting them permission to use the feature. A site can't even query the devices around the user without the user getting a very clear and actionable prompt - so in this case it is nothing like the orientation API.
- ConcernedCoder 8y ago
  So the sheep can't query the interface without the wolf's permission? great... I'll be sleeping so much better tonight.
adrr 8y ago
The industry is trying to replace native apps on mobile devices with web pages.
jdlyga 8y ago
This is an android thing right? They gotta add more fine grained permissions
true_religion 8y ago
Technically, Javascript can already make web requests, whoch when you are on a phone means using wifi or mobile data, both of which are radios. So Javascript has always controlled your radios. This is just one more connection.
jackhack 8y ago
Oh, they're asking "should we" -- they're just not asking the public (the public is the product being sold, after all).
mtgx 8y ago
WebAssembly and PWAs are only going to make this worse, as they give browser vendors an excuse to give websites full access to the user's local machine.
philosopherlawr 8y ago
Get Off My Lawn!
thrower123 8y ago
If some browser application can get bluetooth devices to actually work and do things for it, good for it. I sure as hell have never been able to hehe.
shwetank 8y ago
> And now, random websites can grab control of my radios? With JavaScript? No. Only the user allows it. >FFS. This is like the battery api. Too much time spent on "can we", too little time spent on "should we". The battery API can be tremendously useful on mobile if used effectively. For example, disabling certain animations and high end GPU intensive effects if the battery is less.
baddox 8y ago
Would you complain that web browsers have access to your keyboard and mouse without explicitly asking? If not, then why complain about access to DeviceMotionEvent?

andun 8y ago

All new web standars are a terrible idea to our privacy and security. And for some reason nobody seems to care.

stevehawk 8y ago
My theory on this is becoming - because the nerds that would care all work for the Big Five and as such think it's ok because "we're not evil". Once that crowd gets quieted then there's no on to raise the flags for others.
deleted 8y ago
[deleted]
userbinator 8y ago
People care, but those who do are not working on them and their voices get drowned out by the "push the web forward"/"progress is always good" crowd. I suppose there is a bit of cognitive dissonance among developers of such things too.

jake_the_third 8y ago

I run my(?) browsers in their own separate virtual machines. You loose copy and past and you'll need to set up folder sharing, but shit like this is a non-issue. No major browser vendor (and I mean not a single one) puts users' privacy first. People should treat browsers as the privacy hazard they are.

vbezhenar 8y ago
Why lose copy&paste? Virtualbox supports seamless copy&paste, every other VM probably supports it as well.

kgraves 8y ago

This is also similar to the time that WebUSB[1] was added to Chrome, allowing access to USB devices in the browser. I feel that we are frogs in boiling hot water. [1] https://developers.google.com/web/updates/2016/03/access-usb-devices-on-the-web https://developers.google.com/web/updates/2016/03/access-usb...

chucky 8y ago

FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. In a wider sense, there are legitimate uses for many of these apis. To me it seems like the option would be that some phones would get these apis patched into the browser by the manufacturers instead, and that would run an even higher risk of security problems than when the browser vendors do it. If you don't like your browser application having access to certain hardware in your phone, you can just revoke the permission, and it won't have the access (at least on Android, I have no idea how iOS works in this regard).

gsnedders 8y ago
> FWIW the battery api was first specified when people were still hoping that building phone widgets, launchers etc would be done with web technologies. For such usage, having battery api access in a standard way was of course a necessity. And it was done by Mozilla people working on FFOS, specifically. They had no intention of exposing it to web content IIRC.
- earthscienceman 8y ago
  I still see FFOS as ahead of its time. I really wish it would have worked out better.There's all this jostelling happening between the role of software based apps vs. the role of web content/apps on devices... but in the end every day I see more and more content being served through the web. As browser integration improves (through things like 'web bluetooth') I think we're creeping more closely to the browser essentially being an app sandbox for your hardware/OS. Now, whether this is good or not is left as an exercise to the reader.
tinus_hn 8y ago
I think the original idea was that background JavaScript apps could suspend operations when your battery is running low. It quite an edge case but it’s one of those things that make a web app less than native.

koboll 8y ago

Right? Now imagine phone tilt or battery information on the scale of billions of people. Imagine what you can infer. This person's phone has been tilting less often over the past decade - a trend correlated with, let's say, a more strained gait caused by weight gain. The algorithm markets them more sugary foods, because there's a higher likelihood they're effectively addicted to calories. This other person is letting their battery run down more often - a trend correlated with undiagnosed depression. The algorithm ratchets up the fear and sadness because it infers these will be more effective motivators to buy products. The best part is that this will probably all happen invisibly. GDP and human suffering creeping up slowly, with no human at the helm, and the world none the wiser.

obituary_latte 8y ago
Also, when the phone is upside down (reading in bed), or traveling etc. Scary to think of all the things that could be gleaned.
Brakenshire 8y ago
Does phone tilt really give an acceloremeter data stream? I thought it was just landscape or portrait.
- tokyodude 8y ago
  it does but only while the page is active. As soon as you switch tabs, apps, or your phone locks the data stops

lucideer 8y ago

The Web Bluetooth API asks you for permission every time. Like every new web standard like it. It's still something many users will blindly click through but at least there's that. At least this doesn't seem to be a priority feature for Mozilla yet. MDN doesn't even have proper docs for it. So I'm a bit thankful for that, for now. As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that.

deleted 8y ago
[deleted]
bjt2n3904 8y ago
How kind of them to ask! It has all the charm of someone walking up to my house at four in the morning, and knocking on the door to conduct a survey of which radio stations I listen to. It shouldn't be asking, ever. The answer is such a hard no, it makes me wonder why they even tried.
- vbezhenar 8y ago
  Bluetooth provides useful features for many users, that's why.
  - bjt2n3904 8y ago
    Yes, like making poor estimates of my heart rate, being an insecure keyboard, or occasionally failing to deliver audio to my car speakers. Definitely will be useful in my web browser.
    - salvar 8y ago
      Are you claiming that Bluetooth can never be useful for anyone because you don't find it useful?
- lucideer 8y ago
  Why specifically at four in the morning in your analogy? I mean, door-to-door surveys are a pretty common thing at normal hours of the day, and that seems like a reasonable analogy without the arbitrary time change.

realusername 8y ago

The battery api was removed from Firefox for this reason, it was only used for tracking unfortunately.

diggan 8y ago

> These same questions apply to Bluetooth. Already, such a terrible standard when it comes to privacy. And now, random websites can grab control of my radios? With JavaScript? Nothing wrong can happen with this, for sure! No, this is usually not how new features are being used in the browser (see geolocation). Websites won't be able to scan your nearby devices without asking for permission, and it's up to the user to accept/decline it. I'm actually quite excited over having Bluetooth accessible in the browser. That means that we could build P2P applications that works in the browser, that works even when not connected to a wifi and can talk with nearby computers via Bluetooth, something that has not been possible before (FlyWeb was close at achieving something like that as well)

bjt2n3904 8y ago
Because you know, I've always been on my desktop computer and said... "You know, I'd totally use that cool mesh Bluetooth chat app that's so popular and lets you communicate with people within a 25 yard radius, but ultimately falls back to using WiFi because Bluetooth is impractical for this application. Sadly it's not for desktops. If only I could use my web browser..." No! I've never said that! In fact, no one has ever said "I wish I could use Bluetooth in my browser", except for people who want to collect more data on their users. This is like an idea from Todd on Bojack Horseman. Again, too much time on "could we", not enough time on "should we". Bojack clip in question: https://youtu.be/Ct6EuC1W1gE https://youtu.be/Ct6EuC1W1gE
- diggan 8y ago
  > In fact, no one has ever said "I wish I could use Bluetooth in my browser" I literally just wrote above that I do want that. I also don't care about collecting any data. Guess you have to take my word for that. So now you know one person at least :) I'm not sure where in the world you are, but there are many use cases where meshing clients together is the only way of getting non-restricted network access to each other. The only reason why I think Bluetooth + Browsers are a powerful combination is the fact that it's so easy for people to get started, compared to how desktop works. > I've always been on my desktop computer and said ... No! I've never said that! Great, maybe this is not for you but you should try to consider other peoples point of view as well, that might live on the other side of the planet. Otherwise discussing further becomes rather depressing.

Yaggo 8y ago

> [...] I could look around the picture by tilting my phone. When the fsck did this become a feature? Why did nothing ask me if I was ok giving Facebook access to my hardware? To be precice, by using the device orientation API offered by the browser, Facebook has no access to your hardware any more than it has access to your display hardware by utilizing the DOM API to draw on screen or access to your cellular radio by making a TCP connection. Whether the browser should require your permission (per site?) to use device orientation API, that's debatable. Anyway, that's up to the browser implementation.

koolba 8y ago
> Whether the browser should require your permission (per site?) to use device orientation API, that's debatable. Anyway, that's up to the browser implementation. I think anything that involves making new/more input available to remote sites should require opt in. At the very least it should have a toggle to disable it globally.

matt4077 8y ago

> Why did nothing ask me if I was ok giving Facebook access to my hardware? I'll let you in on a secret: Facebook is also controlling your graphics card, and CPU, and memory. Controlling as in "sending HTML that is then displayed via those hardware components". And just like a media query can "access" your device orientation, panoramic media can adapt to the data from accelerometers. The missing information here is the concept of "secure contexts": https://w3c.github.io/webappsec-secure-contexts/#intro https://w3c.github.io/webappsec-secure-contexts/#intro. Being able to use this data does not mean that it can be send back to the server.

syn0byte 8y ago
That's a misleading non-argument for the actual issue. "Your Wells Fargo bank accounts perfectly safe from bank employees because armored cars are used to transport money. They don't let normal bank employees into the back of those vehicles. Only licensed and bonded security guards are allowed."
Ajedi32 8y ago
"Secure Contexts" just means you're visiting the site over HTTPS. It has nothing to do with restricting the ability of JS to communicate with the internet.

simias 8y ago

>Too much time spent on "can we", too little time spent on "should we". I mean, that's the web summed up in a single sentence. What started as a way to view text and pictures online is now more complicated than many operating systems. You cram all that stuff into a single binary, give lackluster and ever changing controls to manage all that and call it the future. Never attempt to break down the functionality across several dedicated clients that do only one thing and do it well, that's for losers. But I somehow disagree with your statement in that it seems to imply that the people designing that garbage are naive or don't really think about the consequences of what they're doing. That might have been true in the early days of the web when nobody knew exactly what it was going to be but it's clearly not the case now. The folks at Google know exactly what they are doing, making browsers more complicated and easier to interconnect with smartphone is win/win for them. It makes it harder to make a competing browser (anybody attempting to make a new browser these days basically has to fork Chrome or Firefox, and generally they go with the former), you need huge developer resources to maintain and optimize it (look at how hard Firefox is struggling to keep up despite the large number of people working full time on it) and while the big G doesn't control Windows, Mac or Linux they do control Chrome and Android so they have a huge incentive to push everything possible away from desktop OSs and into Chrome. They want Chrome to be the OS. Google is 90's Microsoft with better PR. Well actually it's worse than that because MS didn't usually have access to my private data while google knows almost everything about their users if they have an Android phone and use gmail.

UI_at_80x24 8y ago
>Google is 90's Microsoft with better PR. Well actually it's worse than that because MS didn't usually have access to my private data while google knows almost everything about their users if they have an Android phone and use gmail This is the statement that I have known for years but never put into words. And it rings terrifyingly true.
- dvfjsdhgfv 8y ago
  What is terrifying for me is that when it was happening - and it didn't happen overnight, it was a long process - relatively few people were objecting. The ones who objected were often ridiculed as the tinfoil-hat group. The people who should have been smart enough have been blinded by shiny new releases, the amazing things we can do now, for free. It's only recently that the general public started to discover the ugly truth, whereas we could clearly see it already many years ago!

deleted 8y ago

[deleted]

dtf 8y ago

If you're talking about the DeviceOrientation event [1], it's been shipping in browsers since 2010 [2,3]. It also works on your MacBook. [4] [1] https://w3c.github.io/deviceorientation/ https://w3c.github.io/deviceorientation/ [2] https://caniuse.com/#feat=deviceorientation https://caniuse.com/#feat=deviceorientation [3] https://www.engadget.com/2010/07/06/google-chrome-gets-some-early-device-orientation-plumbing/ https://www.engadget.com/2010/07/06/google-chrome-gets-some-... [4] https://simpl.info/deviceorientation/ https://simpl.info/deviceorientation/ (PS my humble opinion is "yes we should". I like being able to develop a heart rate monitor PWA for my phone, and I don't see what's different from granting some random native app the same access. At least with the web I can read the underlying code.)

vardump 8y ago
> It also works on your MacBook. [4] It did absolutely nothing on my 2015 MacBook (tried Safari, Chrome and Firefox). It does work on 2012 MacBook model on Google Chrome. I guess it only works on MacBook models that supported a mechanical disk — I think the sensor exists in the first place to protect spinning rust disks by parking the heads just before impact.
- dtf 8y ago
  I just noticed that [4] doesn't work on Safari or Firefox either (but does on Chrome) on my MacBook 2010. Maybe it wasn't the best demo of that feature ... The API is pretty well supported on tablets and phones though, which is where the main use case is.
  - Fnoord 8y ago
    Doesn't do anything on my Chrome @ MBP 2015, but then again I use all kind of extensions.

grezql 8y ago

Another one is the Push Notifications in browsers. I always block them. Once you open up such APIs websites will abuse it no matter what.

kmlx 8y ago

hi. i develop webapps that run in the browser. these apps leverage webrtc, battery api, local/session storage, websocket, webvr/xr, webgl, you name it. all have legitimate purposes, all run in a browser under https and none have ever been used for tracking: one app that uses webrtc does one to many broadcasts, another uses webxr/webgl to display 3d vr experiences, etc. these apps are used by tens of thousands on a daily basis. and they’re nothing fancy. my advice is to not dismiss the advantages of the web just because of a few bad apples.

falcolas 8y ago
It's not a few bad apples. It's a shipping container full of rotten apples, and maybe two good ones. That is to say, without the analogy, that it's the ad companies who will abuse these, ruining virtually every web site that exists, and jading users against the technology for the few websites who aren't abusing it.
laumars 8y ago
> my advice is to not dismiss the advantages of the web just because of a few bad apples. Except protecting against the "few bad apples" is exactly what we're supposed to be doing. Eg you made a point that your use cases are all served over HTTPS - why should we be doing this when it adds complexity, adds bandwidth and breaks many legitimate corporate management tools? The reason we bother with TLS is precisely because of "a few bad apples". The point of security is to harden against those bad apples rather than ignore they exist just because developers want a shiny new toy to play with.
- Ajedi32 8y ago
  Which is why the web has the most robust permissions system of any platform, period. Sites that need these features for legitimate purposes can access them, while sites that don't can't.
  - laumars 8y ago
    > Which is why the web has the most robust permissions system of any platform, period. I fundamentally disagree with that. Yes it has a permissions system but is it really all that robust? Let alone the most robust of any platform? First off you're dependant on the browser implementing that correctly (that's not always the case) and often there are thousand different ways you can still do naughty things even if those permissions are implemented correctly. Then there are the thousands of vulnerabilities built into the very design of the web that developers (of both web and browsers) are constantly having to code around (XSS, et al). And that's without even addressing the current problems we have with data leakage and privacy concerns that we seemingly have little control over at all. Compare that to networking where you have VLANs, subnets, firewalls and other network ACLs; or Linux servers where you have tools like SELinux. These tools might not be simple to use from the outset but their certainly a great deal more robust than any of the models the web has offered us thus far.

kinlan 8y ago

Site's can not do anything with Bluetooth API unless the user explicitly granting them permission to use the feature. A site can't even query the devices around the user without the user getting a very clear and actionable prompt - so in this case it is nothing like the orientation API.

ConcernedCoder 8y ago
So the sheep can't query the interface without the wolf's permission? great... I'll be sleeping so much better tonight.

adrr 8y ago

The industry is trying to replace native apps on mobile devices with web pages.

jdlyga 8y ago

This is an android thing right? They gotta add more fine grained permissions

true_religion 8y ago

Technically, Javascript can already make web requests, whoch when you are on a phone means using wifi or mobile data, both of which are radios. So Javascript has always controlled your radios. This is just one more connection.

jackhack 8y ago

Oh, they're asking "should we" -- they're just not asking the public (the public is the product being sold, after all).

mtgx 8y ago

WebAssembly and PWAs are only going to make this worse, as they give browser vendors an excuse to give websites full access to the user's local machine.

philosopherlawr 8y ago

Get Off My Lawn!

thrower123 8y ago

If some browser application can get bluetooth devices to actually work and do things for it, good for it. I sure as hell have never been able to hehe.

shwetank 8y ago

> And now, random websites can grab control of my radios? With JavaScript? No. Only the user allows it. >FFS. This is like the battery api. Too much time spent on "can we", too little time spent on "should we". The battery API can be tremendously useful on mobile if used effectively. For example, disabling certain animations and high end GPU intensive effects if the battery is less.

baddox 8y ago

Would you complain that web browsers have access to your keyboard and mouse without explicitly asking? If not, then why complain about access to DeviceMotionEvent?