Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Android Chrome Desktops (Apple) Google Software The Internet Windows Linux

Chrome Is Nearly Ready To Talk To Your Bluetooth Devices (engadget.com) 151

Posted by msmash from the connected-things dept.
Jon Fingas, writing for Engadget: Don't look now, but your web browser is about to become aware of the devices around you. After months of testing, Google has switched on broader experimental support in Chrome and Chrome OS for Web Bluetooth, which lets websites interact with your nearby Bluetooth gear. You could use a web interface to control your smart home devices, for instance, or send data directly from your heart rate monitor to a fitness coach. At the moment, trying Web Bluetooth requires the stars to align in just the right way. You'll need a pre-release version of Chrome 53, and you'll naturally want to find (or create) a website that uses the tech in the first place.
This discussion has been archived. No new comments can be posted.

Chrome Is Nearly Ready To Talk To Your Bluetooth Devices More

Chrome Is Nearly Ready To Talk To Your Bluetooth Devices

Comments Filter:

  • Do not want (Score:5, Insightful)

    by Anonymous Coward on Tuesday August 09, 2016 @03:11PM (#52673665)

    Please stop this.

    • Would you rather lose the use of an application entirely because you own a Mac and the developer owns a Windows PC or vice versa?

      • Re:If not web, then what OS-independent platform? (Score:5, Insightful)

        by TheGratefulNet ( 143330 ) on Tuesday August 09, 2016 @03:17PM (#52673713)

        yes.

        I won't accept a browser that should be SAFE, touching things it should not.

        another example of the google children not thinking deeply about what they are doing. simply just doing because they CAN rather than because they SHOULD.

        if google is behind it, chances are its invasive and not in your best interest, more often than not.

        sigh......

        • Re: (Score:2, Insightful)

          by tepples ( 727027 )

          I won't accept a browser that should be SAFE, touching things it should not.

          Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account, over a web application running inside a web browser's sandbox. How are native applications more secure than web applications?

          • Re:If not web, then what OS-independent platform? (Score:5, Insightful)

            by TheGratefulNet ( 143330 ) on Tuesday August 09, 2016 @03:25PM (#52673767)

            I can choose NOT to run a closed-source app.

            how do I know that my browser is not doing bad things behind my back? I have a browser open all the time, as do most. that, alone, makes this idea super stupid.

            if I choose to run a BT app, I'll run one that I trust. and I'll end it when I'm done.

            I have zero need for linking in vmlinux to a FUCKING BROWSER and making the fucking thing bootable. given time, the children at google will want to do that, too.

            oh, and systemd needs to be mixed into this somehow. I feel it will be more complete if they do that (lol).

            • I can choose NOT to run a closed-source app.

              True though in practical terms that is of less value security wise than many imagine.

              how do I know that my browser is not doing bad things behind my back?

              Unless you've audited the code of the browser and compiled yourself it with a compiler whose code you also have audited you cannot know if a browser is doing bad things behind your back. That is true whether or not the source code is open source or closed. Open source does have its advantages but it just changes the attack surface rather than eliminating it.

              • There is still a notable difference between knowing you let the browser run on your computer, and knowing you let random websites reach out and meddle with your bluetooth devices.

                • There is still a notable difference between knowing you let the browser run on your computer, and knowing you let random websites reach out and meddle with your bluetooth devices.

                  So this feature is completely behind the scenes and transparent to the user to the point they don't even know it's happening? Or is it more like the webcam and microphone access we've had for years?

                • Re:Different attack surfaces (Score:4, Insightful)

                  by AmiMoJo ( 196126 ) on Wednesday August 10, 2016 @07:05AM (#52676825) Homepage Journal

                  I have bad news for you. All major browsers have been offering web sites access to any attached webcams and microphones for many years now. Of course they ask you if you want to allow access first, and you can set an "always disabled" flag, but the code is in there.

                  I find it quite amusing what Google has done. They build an OS on top of every other OS in the form of a browser, making the underlying system pretty much irrelevant. All apps run in the browser now - Google's office apps, their cloud file storage, video conferencing and soon health monitoring via Bluetooth sensors.

                  I still don't want it.

              • The browser isn't the issue. The issue is the drive-by ad-network delivered malware that people don't even know they're getting when they visit a random site. Even if you go to a site that you trust, there's *still* no guarantee that you're safe because they may serve something malicious by accident. This has happened more than enough times that this scenario should be front and center in everyone's minds.

            • I can choose NOT to run a closed-source app.

              Likewise, you can choose NOT to run a closed-source web app using the LibreJS extension [gnu.org]. It's made for Firefox; I'm not aware of a counterpart for Chrome yet.

            • how do I know that my browser is not doing bad things behind my back? I have a browser open all the time, as do most. that, alone, makes this idea super stupid.

              Are you familiar with FireFox's pop-ups "the website http:/// [http]{whatever}.com has requested access to your webcam/your microphone/your localisation/streaming your desktop/etc." ?

              Webapps in your browser can already get access to your microphone or stream a video of your desktop.
              But 99% of the regular pages don't need it.
              So, the default behaviour is that the few 1% webapps that need special access to some hardware need to first ask for it and a pop-up asks you if you grant access to it.

              A local .html file on you

            • how do I know that my browser is not doing bad things behind my back? I have a browser open all the time, as do most. that, alone, makes this idea super stupid.

              Well you say you have a browser open all the time so you're obviously not very worried about your confidence that it's not doing bad things behind your back right now.

            • oh, and systemd needs to be mixed into this somehow. I feel it will be more complete if they do that (lol).

              That is exactly the point; systemd should be worrying about activating any hot-plugged multimedia devices that would affect the browser experience, and the browser doesn't need to know about it. It just needs to know what audio inputs and outputs it is allowed to use.

              • Re: (Score:2)

                by tepples ( 727027 )

                systemd should be worrying about activating any hot-plugged multimedia devices that would affect the browser experience, and the browser doesn't need to know about it. It just needs to know what audio inputs and outputs it is allowed to use.

                Then how would a web application use Bluetooth devices other than multimedia devices, such as a Bluetooth pedometer?

          • Re: (Score:1)

            by Anonymous Coward

            Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account

            Your presumption is incorrect.

            Native apps can be walled off by lightweight virtualization technologies, or even simply separate user accounts enforced at the kernel level.

            While one could also separate a web browser in this way, having it be the default behavior then requires this separation, where it did not before. There will probably not even be a user level switch to turn the bloody thing off, and anyway such switches have a habit of mysterious disappearances.

            Now, I don't use Chrome, for reasons like th

            • Native apps can be walled off by lightweight virtualization technologies

              Google Chrome already runs inside a sandbox [chromium.org] that provides something akin to the "lightweight virtualization" you suggest.

              or even simply separate user accounts enforced at the kernel level.

              So if a home PC has five users, one for each member of the household, and 50 apps installed, would it need 250 user accounts, one for each member of the Cartesian product of users and apps?

          • Re:If not web, then what OS-independent platform? (Score:5, Insightful)

            by DarkOx ( 621550 ) on Tuesday August 09, 2016 @04:01PM (#52674069) Journal

            Native apps don't usually mix in code from untrusted sources at run time they way basically every web app that includes ads of any kind does.

            Native apps don't usually have comments and data from other untrusted users that would by trying attacks like XSS against me. Native apps won't be vulnerable to CSRF and similar either.

            The web browser is a little to open a platform for giving access to hardware like that.

            • Re: (Score:2)

              by tepples ( 727027 )

              Native apps don't usually have comments and data from other untrusted users that would by trying attacks like XSS against me.

              Not even a mail user agent?

            • Re: (Score:2)

              by AmiMoJo ( 196126 )

              In many ways the browser is actually a good platform for app, so perhaps we should be welcoming this. It's heavily sandboxed and partitioned, and the attack surface is much smaller than for an app running natively on an OS. "Apps", really web sites, don't require installation or updates. It even forces the apps to be somewhat open source, even if they do use a lot of obfuscation and service side processing.

              There are huge down-sides as well, but as a platform the browser isn't the worst one out there.

          • Yet I infer that you'll accept a native application, which presumably has even greater privileges to access the data in your user account, over a web application running inside a web browser's sandbox. How are native applications more secure than web applications?

            Abstract answer to your abstract question many native applications can get by with much less total complexity than required simply to invoke "hello world" on a modern browser stack. What does the browser weigh in at? 10-20 MLOC? All of that on top of cost of OS provided facilities. I bet many applications people use come in way under that.

            Significant reductions of complexity can translate into reduced avenues for error and compromise as complex facilities of modern browsers are not needed.

            As far as runn

          • How are native applications more secure than web applications?

            They're safer because I didn't start them, and I don't feed code from public sources to them to execute. If it isn't running, it isn't going to have a security bug that makes it accessible to some random malware user.

            • Re: (Score:2)

              by tepples ( 727027 )

              They're safer because I didn't start them

              You didn't start a web application either because you didn't whitelist the domain it came from in your script blocker.

              • Right, but that is like saying that malware is OK, because I personally won't be affected by it.

                Also, sometimes, rarely but sometimes, I temporarily allow an otherwise-lame or poorly known domain to use javascript. It has to be considered, I have to know what the dangers are, I can't just ignore the specific dangers; if I did I wouldn't even be able to guesstimate if I'm protected or when.

        • I won't accept a browser that should be SAFE, touching things it should not.

          If you don't want it to touch certain things then enforce those restrictions yourself. For all the complaining about the "dumbing down of computers" I see here there is a persistent attitude that applications should do exactly what you want without you having to do the unthinkable task of customizing it by turning a setting on or off, or restricting what that application has access to.

          If your personal opinion is that it should not have access to those things then don't allow it to. I personally agree with y

          • Re: (Score:2)

            by zlives ( 2009072 )

            it will probably go like this (if not in first iteration but eventually)
            you get a choice!!!

            1.connect Bluetooth devices to your pc (yes/no)
            2.connect browser to bluetooth devices connected to your PC (yes/no)

            so if you want your headset to work with your browser now every bluetoothe device is also available to the ad giant to build a profile.

            • No, it will probably work on a per-site basis given that is how the microphone and webcam functionality works.

      • I certainly would.

        If the application is on Linux I can use it and so can anyone else who cares.
        If it's on Windows I can use it and so can anyone else who cares. Windows is ubiquitous, despite its shittiness. Also emulators exist (yes, WINE is an emulator, it's just not emulating hardware).
        If it's on OSX and only OSX it's likely not worth using.
        If it's on iOS and only iOS it's likely not worth using.
        If it's on Android it's likely not worth using but I can use it and so can anyone else who cares. Windows i

        • Re: (Score:2)

          by tepples ( 727027 )

          Also emulators exist (yes, WINE is an emulator, it's just not emulating hardware).

          Have you had a good experience using Bluetooth devices in applications in Wine, such as a Fitbit device's sync application? AppDB reports Fitbit as "Garbage" because sync does not work [winehq.org].

        • If it's on OSX and only OSX it's likely not worth using.
          You're a retard. And a hater.

          • Look guys, macs4all can't even quote properly. How cute!

            • Look guys, macs4all can't even quote properly. How cute!

              I knew as soon as I posted that some "perfect" Slashtard Pinhead would catch my HTML faux-pas TYPO.

              I'm glad to see that I can depend on the idiot fuckers on here to instantly point out everyone's mistakes but their own...

              Now kindly do the entire internet a favor and immediately and vigorously spontaneously combust, will you?

    • On the other hand, every website in the %#@*ing world wants me to use their terrible app and put their greedy little fingers in my phone rather than let me use their mobile capable website. If this means companies will start relying on browsers again, bring it on and give me more.

    • The alternative being that your smart home devices/your heart rate monitor/security video surveillance camera/any other gizmo gets IoT enabled and uploads all its data to an even less secure cloud server that your controlling app or webapp must talk to.

      It's either direct link to remote control your gizmo.
      Or remote control with a round-trip over internet.

      I really prefer the first route, because it means that some body is going to reverse engineer it and release an opensource library that can talk to your giz

    • Bluetooth Dildos!!!

    • Talk about a solution trying to create a problem, wowsers!

      I hate features more and more all the time.

  • No, it won't (Score:3)

    by somenickname ( 1270442 ) on Tuesday August 09, 2016 @03:13PM (#52673675)

    "Don't look now, but your web browser is about to become aware of the devices around you.".

    No, it will not do that and it will never do that. Because that's a terrible fucking idea.

  • There's a reason every shitstain Intel chipset I use has its bluetooth, NFC, and wifi radios disabled and, where possible, antennas disconnected. I also kill off the IR port.

  • Nope! (Score:3, Insightful)

    by ilsaloving ( 1534307 ) on Tuesday August 09, 2016 @03:21PM (#52673745)

    All aboard the nope-train to nopeville!

    Apparently no one at google ever saw Jurrasic Park, or they would know that scene with the line "Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."

    The internet is a cesspool of fetid, rotting miasma, and you want it to be able to control real world things with no managed server in between? Are they really that thoughtless? Apparently they are!

    • this proves it, time and time again, that CHILDREN are running google

      "hey, neat-o! lets do THIS. and THIS. annnnnnd THIS."

      yeah, children who don't understand that because you can does not mean you should.

      they are totally out of control and mgmt seems to not care. or, mgmt is also filled with twentysomthings who are too new to the world to really get what the implications are of their actions.

      I wish some adults would be in charge of this IoT madness, for a change.

      • More like, "Hey, let's implement this neat feature, and then wait to see if anyone can figure out a way to make it actually useful for something!" When you've got as much cash in hand as Google/Alphabet or Amazon, you can afford to throw a LOT of stuff at the wall just to see what actually sticks.

    • The internet is a cesspool of fetid, rotting miasma, and you want it to be able to control real world things with no managed server in between?

      You mention a "managed server". Could you describe an architecture involving a "managed server" that you would find acceptable?

      • Anything that provides a firewall between the internet and a device. eg: Client software that needs to be manually installed by the user onto their machine, which facilitates communication between the web and a device, in a restricted and controlled manner, only permitting a predefined set of operations to occur.

        • Client software that needs to be manually installed by the user onto their machine

          Which is useless if the client software isn't made for a particular user's PC's operating system, as I mentioned earlier [slashdot.org]. One way to use applications made for a different operating system is through a virtual machine. How easily can a Linux guest access Bluetooth devices paired to the host?

          • At an absolute minimum, *some* process outside of Chrome needs to be the final arbiter of what can reach a Bluetooth device, even if it's just a process that presents the user with a "Yes or No" dialog when a site tries to do anything Bluetooth related.

            There are already enough issues with poorly secured Bluetooth devices. The last thing we need is to roll out the red carpet to every malware author on the planet.

            • At an absolute minimum, *some* process outside of Chrome needs to be the final arbiter of what can reach a Bluetooth device

              Your browser already has access to your network, the filesystem, camera, microphone, etc... and the protections and prompts are in the browser itself. Why is Bluetooth a special case?

              More to the point, people use remote access technologies, web-accessible NAS devices, web-accessible home automation, security systems, etc... all the time, why is Bluetooth suddenly such a worry?

              • Because a) bluetooth security is more often than not, a steaming pile of wank,
                b) Bluetooth is used in a huge variety of places,
                and finally c) the internet is a ridiculously hostile place.

                Internet Explorer has already taught us what can happen when you give a browser too much access to underlying hardware. Hell, drive-by malware infections are *still* an issue, mostly because of shitty ad-networks that happily pass malware onto legitimate sites. It also taught us how ruthlessly malicious actors will jump o

                • Because a) bluetooth security is more often than not, a steaming pile of wank,

                  The artbiter of access to any resource the browser has access to is in the browser itself (if you haven't configured any additional layers of access control). If the user allows access to a specific resource (in this case a bluetooth device) then what part of bluetooth security are you worried about?

                  b) Bluetooth is used in a huge variety of places

                  So are home networks and network-connected devices, your browser has access to this too. Not only that but many people expose their network through various external interfaces other than the browser for home aut

                  • Because a) bluetooth security is more often than not, a steaming pile of wank,

                    The artbiter of access to any resource the browser has access to is in the browser itself (if you haven't configured any additional layers of access control). If the user allows access to a specific resource (in this case a bluetooth device) then what part of bluetooth security are you worried about?

                    Because the browser should *not* be the arbiter of access to hardware. That's the OS's job. Period. A web browser is particularly unique among applications in that it should at no point ever be considered trustworthy enough to have direct system level access, because it regularly deals with potentially hostile information.

                    b) Bluetooth is used in a huge variety of places

                    So are home networks and network-connected devices, your browser has access to this too. Not only that but many people expose their network through various external interfaces other than the browser for home automation, security, etc... and have done for a long time.

                    You basically made my point now. There are literally millions of computers that are constantly being infected by malware of various kinds. And one machine in a household will usually

                    • Because the browser should *not* be the arbiter of access to hardware. That's the OS's job. Period.

                      No it isn't. The OS's job is to provide an interface to the hardware, not access control. However if you feel that is appropriate then go implement it in one of the various FOSS operating systems and prove that it's more secure, clearly it would be in your interest to do so.

                      Bluetooth devices have largely been shielded because of the layers of steps required in order to compromise one. Google is removing a large number of these steps with this new technology, turning it from being a PITA, to trivial

                      Can you be a bit more specific about some of these things? You could trivialize the task of compromising pretty much anything by saying that. Exactly what layers of steps have they removed? And can you explain the PITA compromise that is

                    • No it isn't. The OS's job is to provide an interface to the hardware, not access control. However if you feel that is appropriate then go implement it in one of the various FOSS operating systems and prove that it's more secure, clearly it would be in your interest to do so.

                      I'm not even going to bother addressing the rest of your post, so I can only assume you're trolling me. Either that, or you honestly have no idea what operating systems have been doing for a long time now. Just in case it's the latter, I will explain:

                      Every single operating system today has a multitude of security mechanisms of various forms, and various levels of effectiveness. From ACLs, to Group Policy, to Gatekeeper, to SELinux, security has very much become, if not always been, a crucial part of ever

                    • Every single operating system today has a multitude of security mechanisms of various forms, and various levels of effectiveness. From ACLs, to Group Policy, to Gatekeeper, to SELinux, security has very much become, if not always been, a crucial part of every non-trivial operating system on the planet.

                      That is a user-configurable layer of security, if that's what you meant when you were talking about being the arbiter of access then we already have that. What I mean is that the OS isn't responsible for prompting you every time a process requests a resource, if that is what you want then you could implement that in a FOSS operating system. You can disallow access to resources broadly already and if mechnisms like SELinux are the kind of access control you are talking about then you already have that so wha

  • Problems with BT & Chrome OS on Multiple Devic (Score:5, Interesting)

    by mykepredko ( 40154 ) on Tuesday August 09, 2016 @03:25PM (#52673769) Homepage

    I have been taking advantage of the BT (SPP/RFCOMM) operation in Chrome and ChromeOS for a white now on a variety of devices and for the most part it works quite well. My app is a Chrome App (Extension) in which the code is written in JavaScript.

    Unfortunately, when you have multiple ChromeOS systems (ie Chromebooks) connected to BT devices simultaneously, you experience some weirdness (previously paired devices not being found with a "undefined" error and requiring several connection attempts as well as connections failing after a few minutes). I'm working at figuring out what the problem is.

    The Chrome.Bluetoothsocket discover and connect APIs will find, pair and connect devices quite nicely on all Windows and Linux systems but not Macs. Macs require going into "System Preferences" and pairing your device beforehand. Linux requires something like Blueman to be installed and works reasonably well.

    This could provide some interesting functionality, but I suspect there will be problems with the first implementations along with the issues listed above. It will probably be solid in 2-3 releases (4 to 6 months) after multiple users have identified issues with it.

    • I havent looked at the Chrome SDK for this yet, what are the security implications though? Thats really the question on everyones mind.

    • The problem isn't the technology, it's the ramifications of the technology. You want to take devices where security is, at best, an afterthought and allow them to interact with the internet? That's pure insanity. A web browser is already an enormous attack surface and people want to increase that attack surface by adding devices where security is non-existant? No thanks.

    • Macs require going into "System Preferences" and pairing your device beforehand.

      At least SOMEBODY understands Security...

      • Sorry - I should have noted that if it's a Windows device, the BT pairing dialog boxes come up and unless the PIN is trivial (0000, 1111 or 1234) the user must enter the pin and in either case, the user must confirm that they want to connect the device.

        As noted, if it's a Mac, you must go under "System Preferences".

        If it's a ChromeOS device, there is no user confirmation.

        There is no user confirmation under Linux.

  • HTTPS only. Again. (Score:4, Interesting)

    by tepples ( 727027 ) <tepples@gmai3.14159l.com minus pi> on Tuesday August 09, 2016 @03:30PM (#52673833) Homepage Journal

    Another day, another new web API that's impractical to test across a home or small office LAN, just like Service Workers before it.

    you'll naturally want to find (or create) a website that uses the tech in the first place.

    I have one machine on my home LAN that I want to use as a server, and another machine that I want to use as the client. But from Google's page about this new feature [google.com]:

    HTTPS Only

    Because this experimental API is a powerful new feature added to the Web, Google Chrome aims to make it available only to secure contexts. This means you’ll need to build with TLS in mind.

    It recommends running python -m SimpleHTTPServer on localhost. But that fails if the web server and web browser are running on separate machines, which might be the case if the machine that you are using as a web server to test your app, such as a Raspberry Pi board, is incapable of running Google Chrome or incapable of connecting to Bluetooth devices.

    I personally enjoy GitHub Pages for demo purposes.

    That's fine for demos that have reached the stage where they are ready for public consumption. I'm referring to the stage before that.

    To add HTTPS to your server you’ll need to get a TLS certificate and set it up. Be sure to check out the Security with HTTPS article for best practices there. For info, you can now get free TLS certificates with the new Certificate Authority Let’s Encrypt.

    Let's Encrypt issues certificates only for domains that have either A. publicly reachable dynamic DNS or B. a publicly reachable HTTP server. Neither of these is likely to apply to a machine on a home or small office LAN.

    • Re: (Score:1)

      by Anonymous Coward

      Self-signed certificates are not difficult to generate and install in your browser.

      https://help.github.com/enterprise/11.10.340/admin/articles/using-self-signed-ssl-certificates/

      • Re: (Score:2)

        by tepples ( 727027 )

        An internal CA solves the narrow "developer on a home LAN" issue because a web developer is presumably tech-savvy enough to generate a root certificate and install it on the machine running Chrome. Thank you for your answer.

        Am I allowed to ask a second question about other problems with an HTTPS-only policy that I foresee, related to a home server appliance intended for use by less tech-savvy users on a home LAN? Or would that be moving the goalposts?

    • Re: (Score:3)

      by tepples ( 727027 )

      A related but different question:

      I plan to develop an application that runs on a PC and acts as an HTTPS server that other PCs on the same home LAN can access. It cannot be accessed from the Internet; connections from outside 10/8, 172.16/12, or 192.168/16 are refused to protect the privacy of the information that the application stores.

      I want to make a web application instead of a native application so that I don't have to spend five times as long remaking the application for five different operating syste

    • Re: (Score:3)

      by AmiMoJo ( 196126 )

      For testing you can simply generate your own certificate and manually install it on your PC and server. You only need to buy one if you need it signed by someone in the chain of trust, but if it is just for testing on your own systems then you, as administrator, have the power to trust whatever certs you like.

  • Is this part of that whole cluster-fuck where my fridge automatically orders milk when I'm low?

    No

    Thanks

  • OK, "protected" is maybe not the right word. Microsoft is just not providing support for Bluetooth LE (GATT) prior to Windows 8. I'm assuming Chrome won't be providing their own BT stack.

  • This is dangerous business. Google needs to get this JUST right, or it will be a ridiculously easy-to-exploit attack vector.

    • This is dangerous business. Google needs to get this JUST right, or it will be a ridiculously easy-to-exploit attack vector.

      The problem is that "JUST right" is a state of limited duration. And all too often it's a VERY limited duration. As for Google getting it 'just right', even for 5 minutes - well, I suspect they really don't give a flying fuck, considering that they regard us all as mere experimental subjects anyway. We're all basically lab rats as far as Google is concerned.

  • Just let the damn browser be a browser, stop building O/S capabilities into Browsers, we don't need local storage, we don't need DRM we just want it to open and render web pages.

    • Re: (Score:3)

      by tepples ( 727027 )

      Because developers want to deploy applications to users of Windows, macOS, X11/Linux, iOS, and Android. A native application works only on a single operating system unless separate native applications are made for each operating system. If accessing local storage, the camera, Bluetooth, or other features of your computing device requires a native operating system, then it'll likely end up being your preferred operating system that gets left out.

  • I'm not ready for Chrome to talk to my bluetooth devices. I mean, I cannot imagine how that's going to be misused.

  • My bluetooth-powered ad-blocker is almost complete.

Slashdot Top Deals

Avoid strange women and temporary variables.

Close