The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up. Chrome implemented both, extension authors happily started using it.
Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.
Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.
However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.
But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.
Note that without the hardware part, the whole system cannot survive a hard drive wipe. So it's semi-useless for existing hardware not equipped with it, and my point is that the original question was about exactly this situation. Not to lessen the merits of the solution, of course - it's just not applicable.
Besides, Computrace persistency module will only re-enable itself under supported operating systems. Guess if Linux is included! So the surviving module will be running on firmware/BIOS level only, and I personally consider that "hardware".
You definitely can't call accounting software "ordinary", at least not in terms of risks. It operates in an area with high legal risks for its users in case of an error, and it's not a revelation for the developers of said class of software.
Something I do not understand in this whole rhetoric - what's stopping Sony from doing the very same thing? How's that's an argument? Any future mandatory software/firmware upgrade can alter the way it operates. See OtherOS problem. So, what makes MS more likely to play that card?
I'm also contributing to the development of its notifier extension for Chrome, shaping it to be a more useful tool, in the spirit of "I have to live with that, may as well improve it".
Well, my point wasn't that the original card is impossible to clone given physical access to the card. My point is that using only radio communication with the chip, it is not possible to clone it. I imagine that NFC stuff and the crypto module are isolated, and the hardware crypto module quite literally has only one command exposed, to generate a response to a challenge. So neither passive (when you hear the challenge and the response) nor active (when you can submit challenges yourself) attacks can give you the required key, even if you can find a bug in NFC that you can exploit.
As for complex protocols. I'm a logician working with proof theory. There have been precedents of full formal verifications of such protocols that, given a set of assumptions about the hardware, can exclude any possibility of a flaw in the protocol itself. Example 1, example 2. It's usually very hard, but can be done, and gives the same rigor as normal mathematical proofs.
Smart card security isn't new. So it's a reasonably mature concept, but it has usability problems in this application.
And I will just repeat what I said when they first came out- why do we need this? Swiping a card is not difficult nor time consuming. Yet contactless is more expensive, more complex, and has remote "skimming" possible issues. It is far enough distance to be potentially dangerous, but not enough to be REALLY convenient (like leaving it in your pocket or purse). Meanwhile, the only problem with the old [card] tech has been reliance on magnetic strips that can and do wear out or get erased. So replace them with invisible IR barcodes or something. Or maybe *contact-full* chips that require touching something.
Contactless payments differ a lot from magnetic stripe swiping, invisible barcodes etc.
They are not static information but an active challenge-response authentication system. You cannot clone the chip; it has an internal cryptographic secret it does not allow you to access, only challenge responses. You can trick it into authorizing a purchase you don't want if you're in physical proximity, which is happening here, but you cannot save that authorization for later use, since the bank is issuing the challenge here, just like with a chip-and-pin purchase. The whole point is to ensure that this is really the actual card.
So the main problem is the lack of user interaction to go ahead with the purchase. A touch button on the card itself would help, but would destroy part of the convenience.
The burden should really be on the patent submitter to point out exactly what is so innovative as do deserve a government enforced monopoly over the approach. If the patent is 90% mundane details, it should not be the job of the patent office to pick out what is worthwhile. If the submitter cannot make a concise and convincing argument, then they don't deserve a patent.
Then it falls back to the patent office to pick out which arguments are convincing, which is a pretty much similar task.
It's not exactly an efficient sink, is it? Your only option for heat transfer "outside" is infrared radiation, since vacuum does not exactly support conduction/convection.
There is a difference between knowing and remembering. Especially remembering the first version of it. And my comment was due to the fact that the original comment was at -1 and I had no mod points.
Won't be enough. This only stops the sync, leaving the local data intact. What you want is to delete the Chrome "User", which is there in the non-advanced settings, "Delete this user" button.
You seem not to be talking to each other. This was not at all about data on the Chromebook itself. Only the fact that Google Sync pulled very sensitive data by default.
Slashdot Mirror
So is importing, in some countries.
Wrong. Since I follow the situation closely, let me explain.
The HTML5 Web Notifications API is in Chrome since forever under webKitNotifications.
The first draft spec of Notifications API included both icon-and-text simplistic notifications, and HTML notifications which were in fact just tiny windows that popped up.
Chrome implemented both, extension authors happily started using it.
Next, W3C drops HTML notifications from the draft. Chrome then drops it from the web context, but keeps it for extensions: they didn't want to suddenly break legacy apps, I guess. They didn't even mark it as deprecated until not long ago.
Fast forward a few releases. Chrome wants its own notifications center, and drafts a new Rich Notifications API. Long experimental, this finally hit Stable.
However.. Despite being touted as a replacement for HTML notifications, those don't come even close to customization possibilities of an arbitrary HTML page, with its own code running. And Google decided to make a hard switch: a browser version has either Rich or HTML notifications enabled. So, if the feature hit you, your old notifications keel over and die immediately.
But that's not the worst problem here. The worst problem is sudden fragmentation. Windows and Chrome OS have the new Rich notifications and do not have HTML ones anymore. OS X and Linux do not have Rich notifications but support HTML ones. See the problem? And despite saying that it will come to other platforms "soon" this isn't in Beta yet for sure, and possibly not even in the Dev branch, but don't quote me on that. So to even maintain both systems I now need two OSes.
In Russian we have a good umbrella term for what was described: silovik, "people of force".
Note that without the hardware part, the whole system cannot survive a hard drive wipe. So it's semi-useless for existing hardware not equipped with it, and my point is that the original question was about exactly this situation. Not to lessen the merits of the solution, of course - it's just not applicable.
Besides, Computrace persistency module will only re-enable itself under supported operating systems. Guess if Linux is included!
So the surviving module will be running on firmware/BIOS level only, and I personally consider that "hardware".
You definitely can't call accounting software "ordinary", at least not in terms of risks.
It operates in an area with high legal risks for its users in case of an error, and it's not a revelation for the developers of said class of software.
Note it's a hardware solution, while the question as about a software solution for existing hardware.
Replying to undo accidental downmod, sorry.
Something I do not understand in this whole rhetoric - what's stopping Sony from doing the very same thing? How's that's an argument?
Any future mandatory software/firmware upgrade can alter the way it operates. See OtherOS problem.
So, what makes MS more likely to play that card?
I will also vote for The Old Reader.
I'm also contributing to the development of its notifier extension for Chrome, shaping it to be a more useful tool, in the spirit of "I have to live with that, may as well improve it".
Well, my point wasn't that the original card is impossible to clone given physical access to the card. My point is that using only radio communication with the chip, it is not possible to clone it. I imagine that NFC stuff and the crypto module are isolated, and the hardware crypto module quite literally has only one command exposed, to generate a response to a challenge. So neither passive (when you hear the challenge and the response) nor active (when you can submit challenges yourself) attacks can give you the required key, even if you can find a bug in NFC that you can exploit.
As for complex protocols. I'm a logician working with proof theory. There have been precedents of full formal verifications of such protocols that, given a set of assumptions about the hardware, can exclude any possibility of a flaw in the protocol itself. Example 1, example 2. It's usually very hard, but can be done, and gives the same rigor as normal mathematical proofs.
Smart card security isn't new. So it's a reasonably mature concept, but it has usability problems in this application.
And I will just repeat what I said when they first came out- why do we need this? Swiping a card is not difficult nor time consuming. Yet contactless is more expensive, more complex, and has remote "skimming" possible issues. It is far enough distance to be potentially dangerous, but not enough to be REALLY convenient (like leaving it in your pocket or purse). Meanwhile, the only problem with the old [card] tech has been reliance on magnetic strips that can and do wear out or get erased. So replace them with invisible IR barcodes or something. Or maybe *contact-full* chips that require touching something.
Contactless payments differ a lot from magnetic stripe swiping, invisible barcodes etc.
They are not static information but an active challenge-response authentication system. You cannot clone the chip; it has an internal cryptographic secret it does not allow you to access, only challenge responses. You can trick it into authorizing a purchase you don't want if you're in physical proximity, which is happening here, but you cannot save that authorization for later use, since the bank is issuing the challenge here, just like with a chip-and-pin purchase. The whole point is to ensure that this is really the actual card.
So the main problem is the lack of user interaction to go ahead with the purchase. A touch button on the card itself would help, but would destroy part of the convenience.
The burden should really be on the patent submitter to point out exactly what is so innovative as do deserve a government enforced monopoly over the approach. If the patent is 90% mundane details, it should not be the job of the patent office to pick out what is worthwhile. If the submitter cannot make a concise and convincing argument, then they don't deserve a patent.
Then it falls back to the patent office to pick out which arguments are convincing, which is a pretty much similar task.
where Microsoft wanted to automate the "tedious chore of composing music"
[citation needed], I can't find this line anywhere.
No, frankly, I cannot imagine millions of users with pitchforks and refund claims. I doubt this would motivate a lot of them.
It's not exactly an efficient sink, is it? Your only option for heat transfer "outside" is infrared radiation, since vacuum does not exactly support conduction/convection.
There is a difference between knowing and remembering. Especially remembering the first version of it.
And my comment was due to the fact that the original comment was at -1 and I had no mod points.
Mod parent up! Actually true.
More like, we should expect Minecraft Pro sometime later as a spin-off of this.
Well, not strictly everywhere..
Won't be enough. This only stops the sync, leaving the local data intact.
What you want is to delete the Chrome "User", which is there in the non-advanced settings, "Delete this user" button.
You seem not to be talking to each other. This was not at all about data on the Chromebook itself. Only the fact that Google Sync pulled very sensitive data by default.
There's a very good "rant" on preordering by TotalBiscuit after Colonial Marines came out: https://www.youtube.com/watch?v=mf5Uj4XIT1Y
Read it quick before Games Workshop assumes ownership of the page!
FTFY
I wonder, does it come with commando line interface?
1 Library of Congress ~ 10Tb of data
Therefore, the database will be around 30 LoCs in size.
But, if we consider this database as part of the Library of Congress, we get a fixpoint problem..