Nope, Fuchsia is a microkernel inspired by Spring, seL4 and others. The low-level APIs are very different from Linux, as is the structure of the OS. It is able to run the Android Runtime, and can support a POSIX compatibility layer (though that's not what it's designed for).
That said, recent Android's Project Treble moves a load of device drivers out of the Linux kernel and into userspace, which would make it much easier to provide versions that work with both Linux and Fuchsia.
never provide your real name to these systems and they can't know it
They can't know it. Until you communicate with someone who has your real name in their contact details. Or you buy anything from a shop that has a data sharing agreement with Facebook and they provide the name from your credit card to associate with the cookie that Facebook set. Or someone tags you in a photograph with your real name and someone else tags you with your Facebook name. Or they identify your home IP and associate that with your entry on the electoral roll. Or one of a dozen other ways in which they can get your real name.
I have five or six false names I use consistently when I want to poison a database so it thinks it has my real name.
Thinking that you're actually doing that may make you feel better, but it's wishful thinking.
There's a more passive form. Things like the Facebook app request permission to access your contacts. Facebook then spams everyone that you know who doesn't have an account already, and may associate all of the information that you have about that person (name, address, email address, possibly date of birth, maybe picture) with their profile of that person. I'm pretty sure that this is a violation of the GDPR, so it will be interesting to see what happens when that comes into effect.
In English Common Law countries, the legal test for whether a contract is valid is whether a 'meeting of minds' has occurred. A signature is typically not legal as a result of any statute law, but is considered legally binding because of a body of case law that argues that it is a strong indication that a meeting of minds has occurred, though with some caveats (a witnessed signature with each page initialled is, for example, considered to be stronger evidence and for some contracts the lack of such a thing would be considered surprising). There is very little case law regarding click-through agreements and so any court would likely weigh the case on its merits individually. Facebook would have to prove in court that a typical reader who clicked on the agree button understood the terms, or at least was able to understand the terms. I suspect that they'd have a hard job doing this.
They don't give the information to anyone. They sell the information to some people. And periodically they just leave it lying around where anyone with a tiny amount of technical knowledge can grab it. But they don't give it to anyone!
Do you really think that it's difficult for Facebook to figure out your real name if you don't provide it but do, for example, have friends that give it access to their phone contacts? I've had a couple of people post my real name in response to Slashdot posts even though I never use it here, and that's without the aid of a massive data mining machine.
I've never signed up for FB. Do they gather info on me?
Yes. If any of your friends have allowed Facebook access to their contacts, then they will have put you in a social graph. If you don't clear or block Facebook tracking cookies, they will record your web browsing.
Does FB sell info on me? I have no membership and therefore no relationship (using the term in a legal sense) and therefore never agreed to letting them gather or sell or aggregate info on me. I think they have said in the past that they only gather public information, which anyone has a right to do.
That's a good question and it's going to be interesting to see how the GDPR changes the answer.
Maybe FB is a top secret section of the NSA?
A big chunk of their startup capital came from a fund that is allegedly a CIA front, not NSA. It's Google that has a revolving door for employees with the NSA.
I think you're the tenth person to attack the same straw man that has absolutely nothing to do with how the WebAuthn design actually works. Do you get some kind of prize?
Neither. You use a user name as a login. You use the fingerprint scanner to authorise your device to provide an attestation. The attestation is something signed with a private key, where you have previously updated a (unique) public key to the site. You may store a set of keys identified by {user, site} pairs, or you might generate the private keys from a {user, site, secret} triple and provide the associated public key on demand. The latter is what most U2F devices do, so if someone steals the device they have no means of enumerating all of the sites that it's valid for.
Typically, when you upload the public key, you'll associate some convenient name with it. Next time you log in with some recovery information or with another registered authenticator you can just go to the list and disable that one.
The API is not about providing biometrics to the remote server, it is about generating keypairs and attestations. When you register a device with a site, you generate a key pair associated with the {authenticator, site, user} triple. The authenticator (U2F device, keychain, whatever) stores the private key, you upload the public key. When you want to log back in, the server provides you with some data, which you then sign with the private key and upload. The server can then check it with the public key and validate that you are the same person as last time.
This means that you never upload a password, biometrics, or anything else of this nature to the web site. You may use biometrics, a hardware security module, or a password locally to authorise the authenticator to provide the attestation.
A typical use case is logging in with a bluetooth U2F device with a fingerprint reader. When you want to log in, the web browser sends the data to sign to the U2F device. It then waits until you put your finger on the reader. If you don't, nothing happens. If you do then it signs the data and the web browser provides the attestation to the server. At no point does your fingerprint data even leave the U2F device.
There are a few problems with client certs as used with HTTPS. The first is that it's difficult to integrate the selection of a client cert with the login UI. Actually, in most browsers, it's pretty hard to have multiple client certs for a single web site at all (try it some time). Second, the JavaScript APIs for generating and installing client certs are pretty horrible. It also requires that the client cert be used as part of every TLS handshake in every HTTPS connection, which adds some latency when you're doing multiple requests to the same site.
This API is designed to make it easy to generate a keypair, provide the public key to the remote site, and lock the private key somewhere. In particular, it allows the private key to be stored in a separate process (e.g. the Keychain on macOS / iOS) and never given to the web browser, or stored in an entirely separate device (e.g. a UbiKey U2F device). The browser or other user agent then exposes a unified API to allow the server to request a keypair be generated for a particular site and to request that something be signed to verify that the client has the private key that matches the public key that the server stored the first time.
As I understand the API, it is designed so that the server never stores anything that might be reused across sites, so even if you use a single password / fingerprint / face scan / blood sample to log into everything, that never leaves your local device and each site gets a key that is uniquely associated with that {authenticator, user, site} triple, where the authenticator is one of a service provided by your OS, functionality provided by your browser, a U2F device, and so on.
Right? About the only thing worse would be a kernel vulnerability in something silly like fonts
Windows and Linux have both had font handling vulnerabilities. The difference is that in Windows they were in the kernel, whereas in Linux they were in X11, which ran with root privilege and could open/dev/kmem and directly modify kernel memory.
The beep vulnerability makes a lot of sense, actually.
No it doesn't. All *NIX operating systems provide standard UNIX file permissions on device nodes and accessing/dev/dsp or the device for the internal speaker to a group is trivial. Most modern *NIX systems provide ACLs, so you can provide finer-grained access. Most modern *NIX systems even provide access control frameworks that let you grant access on a {program, file} pair, rather than, a {user, file} pair, so you could grant access to the device to the beep program running at any user, but not grant any other rights to the program or the user. These vulnerabilities are in no way intrinsic to the beep program, they are related to how the beep program is installed.
I've not read the latest draft, but the earlier version of this spec was basically U2F with enough abstraction to avoid tying it to a specific hardware implementation. The goal was to have the user agent generate authentication tokens and accept responsibility for identifying the user, possibly using a hardware token, possibly using a separate process that handles credentials. I don't think uploading biometric data is part of the spec (unless it's changed), but using biometrics locally to authorise access to credentials is.
They're bikes that you can rent for a short term. The dockless bit means that you can leave them anywhere. They were rolled out here a while ago by a Chinese-owned company. You install their app and can then use it to unlock any bikes you find (they also have GPS and send their location periodically, so you can see where the nearest ones are), then you pay a small amount for as long as the bike is assigned to you, and then you leave them.
They're more expensive than just buying a cheap bike if you cycle a lot, but if you're just visiting then they're a fairly convenient way of getting a bike. Unfortunately, unlike the docked versions that are common in big cities, the lack of well-defined locations means that you may find that you want one and the nearest one is miles away. They also are left in silly places by their last rider, so they clutter up the area a bit. Oh, and they're usually ridden by people who don't cycle regularly and so you need to give them quite a lot of space because the odds that they're about to do something dangerous are pretty high...
You think he's sour now, wait till all the celebrities and newscorps figure out that they have even less influence than they thought when people ignore their hysterical cries and continue using facebook.
It would help if they weren't hypocrites. How many news articles have you seen telling everyone how bad Facebook is with a 'share on Facebook' link right at the top or bottom? Even the Mozilla announcement of a plugin to sandbox Facebook had one of these buttons.
It's astonishing how naive people are when they post things like this. That profile is associated with your browser's cookies and every web site that uses Facebook ads, Facebook-hosted scripts, or a Facebook-hosted button. It is associated with the IP addresses where you log in most often and the associated GeoIP information. It is associated with all of the contacts that have exchanged messages with you. It is fed by any Facebook messages where people address you by name or wish you happy birthday. It is associated with the credit card details (name and address) of any shop where you make a purchase that shares data with Facebook.
So, yes, I think they will have fun scraping useful data from it.
AOL was useful because of the services that ran on it. It died as those services moved elsewhere, gradually. Facebook is valuable because of the other people on Facebook. Each person who leaves slightly reduces the utility to everyone else. For each person, there is a threshold where Facebook's value drops significantly when they can only reach a certain subset of their friends via it. When that tipping point is reached, the person leaves and there's a chance that they'll push someone else across that threshold. I expect to see the death of Facebook as a slow trickle that very rapidly turns into everyone leaving. I wouldn't like to predict whether the current scandals will be the trigger though.
The version that shipped with NT4 supported long file names - it was a straight port of the NT3.51 version where it was default and had to support long file names because NTFS did from the start. Windows 95 just included the 3.11 version. I seem to recall that you could just copy the NT version to a 95 system and have it work. I also vaguely remember that Windows 98 imported the NT version.
Other standards at the same time did, in particular the Common Desktop Environment. The X11 protocol still works and Motif was open sourced so you can still run 1993 Motif apps on a modern X system. For a given value of run...
Command-line stuff? Sure. Graphical stuff? Not so much. The core X11 protocol is the same, but a bunch of early X applications used X extensions that are no longer working well (or supported at all) on modern X systems. And that's assuming a statically-linked binary. Getting hold of early versions of KDE libraries is painful. Motif programs may work with an updated library, but copy and paste are now done differently by FD.o apps so don't expect copy and paste or drag and drop to work (you might have working middle-button paste of plain text, but nothing structured).
This is not quite true. On FAT, files had an 8-byte name and a 3-byte type. These were separate fields (though you could have two files with the same name but different types). They were exposed in the command line using a dot as a separator, so you could access the type easily. FAT also included a few other fields, such as a system flag and an archive flag (set when the file was modified so that it could be backed up incrementally).
On HFS, files had two 4-byte types, one to identify the underlying type and one to identify the preferred app for opening the file. On *NIX filesystems there was no type and so the type was encoded in the name, using a dot as a separator (dot is a valid character in the name, so this also allowed things like.tar.gz).
*NIX filesystems and NTFS now also include extended attributes, which allow you to store arbitrary bits of metadata relating to a file, most commonly used for ACLs or per-file encryption / compression. Unfortunately, interoperability has meant that everyone converges on the lowest common denominator and so stores file types as part of the name.
Oh, and before you extoll the virtues of libmagic, I suggest that you look at its CVE list. It's always fun when simply viewing a file in a file browser can compromise your system, without even having to open it...
Slashdot Mirror
Nope, Fuchsia is a microkernel inspired by Spring, seL4 and others. The low-level APIs are very different from Linux, as is the structure of the OS. It is able to run the Android Runtime, and can support a POSIX compatibility layer (though that's not what it's designed for).
That said, recent Android's Project Treble moves a load of device drivers out of the Linux kernel and into userspace, which would make it much easier to provide versions that work with both Linux and Fuchsia.
never provide your real name to these systems and they can't know it
They can't know it. Until you communicate with someone who has your real name in their contact details. Or you buy anything from a shop that has a data sharing agreement with Facebook and they provide the name from your credit card to associate with the cookie that Facebook set. Or someone tags you in a photograph with your real name and someone else tags you with your Facebook name. Or they identify your home IP and associate that with your entry on the electoral roll. Or one of a dozen other ways in which they can get your real name.
I have five or six false names I use consistently when I want to poison a database so it thinks it has my real name.
Thinking that you're actually doing that may make you feel better, but it's wishful thinking.
There's a more passive form. Things like the Facebook app request permission to access your contacts. Facebook then spams everyone that you know who doesn't have an account already, and may associate all of the information that you have about that person (name, address, email address, possibly date of birth, maybe picture) with their profile of that person. I'm pretty sure that this is a violation of the GDPR, so it will be interesting to see what happens when that comes into effect.
In English Common Law countries, the legal test for whether a contract is valid is whether a 'meeting of minds' has occurred. A signature is typically not legal as a result of any statute law, but is considered legally binding because of a body of case law that argues that it is a strong indication that a meeting of minds has occurred, though with some caveats (a witnessed signature with each page initialled is, for example, considered to be stronger evidence and for some contracts the lack of such a thing would be considered surprising). There is very little case law regarding click-through agreements and so any court would likely weigh the case on its merits individually. Facebook would have to prove in court that a typical reader who clicked on the agree button understood the terms, or at least was able to understand the terms. I suspect that they'd have a hard job doing this.
They don't give the information to anyone. They sell the information to some people. And periodically they just leave it lying around where anyone with a tiny amount of technical knowledge can grab it. But they don't give it to anyone!
Do you really think that it's difficult for Facebook to figure out your real name if you don't provide it but do, for example, have friends that give it access to their phone contacts? I've had a couple of people post my real name in response to Slashdot posts even though I never use it here, and that's without the aid of a massive data mining machine.
New Statesman did that and wasn't able to show any change in advertising as a result of talking near the phone. That said, this doesn't mean that they won't use recorded audio in the future and it doesn't mean that they didn't temporarily disable this feature when it started to get a lot of press.
It doesn't look too different from a system that I remember seeing on Tomorrow's World 20-25 years ago and the time to make the house was similar.
I've never signed up for FB. Do they gather info on me?
Yes. If any of your friends have allowed Facebook access to their contacts, then they will have put you in a social graph. If you don't clear or block Facebook tracking cookies, they will record your web browsing.
Does FB sell info on me? I have no membership and therefore no relationship (using the term in a legal sense) and therefore never agreed to letting them gather or sell or aggregate info on me. I think they have said in the past that they only gather public information, which anyone has a right to do.
That's a good question and it's going to be interesting to see how the GDPR changes the answer.
Maybe FB is a top secret section of the NSA?
A big chunk of their startup capital came from a fund that is allegedly a CIA front, not NSA. It's Google that has a revolving door for employees with the NSA.
I think you're the tenth person to attack the same straw man that has absolutely nothing to do with how the WebAuthn design actually works. Do you get some kind of prize?
Neither. You use a user name as a login. You use the fingerprint scanner to authorise your device to provide an attestation. The attestation is something signed with a private key, where you have previously updated a (unique) public key to the site. You may store a set of keys identified by {user, site} pairs, or you might generate the private keys from a {user, site, secret} triple and provide the associated public key on demand. The latter is what most U2F devices do, so if someone steals the device they have no means of enumerating all of the sites that it's valid for.
Typically, when you upload the public key, you'll associate some convenient name with it. Next time you log in with some recovery information or with another registered authenticator you can just go to the list and disable that one.
The API is not about providing biometrics to the remote server, it is about generating keypairs and attestations. When you register a device with a site, you generate a key pair associated with the {authenticator, site, user} triple. The authenticator (U2F device, keychain, whatever) stores the private key, you upload the public key. When you want to log back in, the server provides you with some data, which you then sign with the private key and upload. The server can then check it with the public key and validate that you are the same person as last time.
This means that you never upload a password, biometrics, or anything else of this nature to the web site. You may use biometrics, a hardware security module, or a password locally to authorise the authenticator to provide the attestation.
A typical use case is logging in with a bluetooth U2F device with a fingerprint reader. When you want to log in, the web browser sends the data to sign to the U2F device. It then waits until you put your finger on the reader. If you don't, nothing happens. If you do then it signs the data and the web browser provides the attestation to the server. At no point does your fingerprint data even leave the U2F device.
There are a few problems with client certs as used with HTTPS. The first is that it's difficult to integrate the selection of a client cert with the login UI. Actually, in most browsers, it's pretty hard to have multiple client certs for a single web site at all (try it some time). Second, the JavaScript APIs for generating and installing client certs are pretty horrible. It also requires that the client cert be used as part of every TLS handshake in every HTTPS connection, which adds some latency when you're doing multiple requests to the same site.
This API is designed to make it easy to generate a keypair, provide the public key to the remote site, and lock the private key somewhere. In particular, it allows the private key to be stored in a separate process (e.g. the Keychain on macOS / iOS) and never given to the web browser, or stored in an entirely separate device (e.g. a UbiKey U2F device). The browser or other user agent then exposes a unified API to allow the server to request a keypair be generated for a particular site and to request that something be signed to verify that the client has the private key that matches the public key that the server stored the first time.
As I understand the API, it is designed so that the server never stores anything that might be reused across sites, so even if you use a single password / fingerprint / face scan / blood sample to log into everything, that never leaves your local device and each site gets a key that is uniquely associated with that {authenticator, user, site} triple, where the authenticator is one of a service provided by your OS, functionality provided by your browser, a U2F device, and so on.
Right? About the only thing worse would be a kernel vulnerability in something silly like fonts
Windows and Linux have both had font handling vulnerabilities. The difference is that in Windows they were in the kernel, whereas in Linux they were in X11, which ran with root privilege and could open /dev/kmem and directly modify kernel memory.
The beep vulnerability makes a lot of sense, actually.
No it doesn't. All *NIX operating systems provide standard UNIX file permissions on device nodes and accessing /dev/dsp or the device for the internal speaker to a group is trivial. Most modern *NIX systems provide ACLs, so you can provide finer-grained access. Most modern *NIX systems even provide access control frameworks that let you grant access on a {program, file} pair, rather than, a {user, file} pair, so you could grant access to the device to the beep program running at any user, but not grant any other rights to the program or the user. These vulnerabilities are in no way intrinsic to the beep program, they are related to how the beep program is installed.
I've not read the latest draft, but the earlier version of this spec was basically U2F with enough abstraction to avoid tying it to a specific hardware implementation. The goal was to have the user agent generate authentication tokens and accept responsibility for identifying the user, possibly using a hardware token, possibly using a separate process that handles credentials. I don't think uploading biometric data is part of the spec (unless it's changed), but using biometrics locally to authorise access to credentials is.
Huh, I remember Motif being open sourced, but apparently I missed the rest of CDE. I used it on Solaris for a while but it was pretty dated even then.
They're bikes that you can rent for a short term. The dockless bit means that you can leave them anywhere. They were rolled out here a while ago by a Chinese-owned company. You install their app and can then use it to unlock any bikes you find (they also have GPS and send their location periodically, so you can see where the nearest ones are), then you pay a small amount for as long as the bike is assigned to you, and then you leave them.
They're more expensive than just buying a cheap bike if you cycle a lot, but if you're just visiting then they're a fairly convenient way of getting a bike. Unfortunately, unlike the docked versions that are common in big cities, the lack of well-defined locations means that you may find that you want one and the nearest one is miles away. They also are left in silly places by their last rider, so they clutter up the area a bit. Oh, and they're usually ridden by people who don't cycle regularly and so you need to give them quite a lot of space because the odds that they're about to do something dangerous are pretty high...
You think he's sour now, wait till all the celebrities and newscorps figure out that they have even less influence than they thought when people ignore their hysterical cries and continue using facebook.
It would help if they weren't hypocrites. How many news articles have you seen telling everyone how bad Facebook is with a 'share on Facebook' link right at the top or bottom? Even the Mozilla announcement of a plugin to sandbox Facebook had one of these buttons.
It's astonishing how naive people are when they post things like this. That profile is associated with your browser's cookies and every web site that uses Facebook ads, Facebook-hosted scripts, or a Facebook-hosted button. It is associated with the IP addresses where you log in most often and the associated GeoIP information. It is associated with all of the contacts that have exchanged messages with you. It is fed by any Facebook messages where people address you by name or wish you happy birthday. It is associated with the credit card details (name and address) of any shop where you make a purchase that shares data with Facebook.
So, yes, I think they will have fun scraping useful data from it.
AOL was useful because of the services that ran on it. It died as those services moved elsewhere, gradually. Facebook is valuable because of the other people on Facebook. Each person who leaves slightly reduces the utility to everyone else. For each person, there is a threshold where Facebook's value drops significantly when they can only reach a certain subset of their friends via it. When that tipping point is reached, the person leaves and there's a chance that they'll push someone else across that threshold. I expect to see the death of Facebook as a slow trickle that very rapidly turns into everyone leaving. I wouldn't like to predict whether the current scandals will be the trigger though.
The version that shipped with NT4 supported long file names - it was a straight port of the NT3.51 version where it was default and had to support long file names because NTFS did from the start. Windows 95 just included the 3.11 version. I seem to recall that you could just copy the NT version to a 95 system and have it work. I also vaguely remember that Windows 98 imported the NT version.
Other standards at the same time did, in particular the Common Desktop Environment. The X11 protocol still works and Motif was open sourced so you can still run 1993 Motif apps on a modern X system. For a given value of run...
Command-line stuff? Sure. Graphical stuff? Not so much. The core X11 protocol is the same, but a bunch of early X applications used X extensions that are no longer working well (or supported at all) on modern X systems. And that's assuming a statically-linked binary. Getting hold of early versions of KDE libraries is painful. Motif programs may work with an updated library, but copy and paste are now done differently by FD.o apps so don't expect copy and paste or drag and drop to work (you might have working middle-button paste of plain text, but nothing structured).
Microsoft Office uses OLE extensively. Any object embedded in an MS Office document is (was?) an OLE object.
On HFS, files had two 4-byte types, one to identify the underlying type and one to identify the preferred app for opening the file. On *NIX filesystems there was no type and so the type was encoded in the name, using a dot as a separator (dot is a valid character in the name, so this also allowed things like .tar.gz).
*NIX filesystems and NTFS now also include extended attributes, which allow you to store arbitrary bits of metadata relating to a file, most commonly used for ACLs or per-file encryption / compression. Unfortunately, interoperability has meant that everyone converges on the lowest common denominator and so stores file types as part of the name.
Oh, and before you extoll the virtues of libmagic, I suggest that you look at its CVE list. It's always fun when simply viewing a file in a file browser can compromise your system, without even having to open it...