Speaking of 'harvesting data', it would be interesting to see what sorts of URLs end up showing up.
There are always privacy implications if you want to provide genuinely useful input on why a system crashed, since a crash dump can be very informative indeed about what the user was doing when the crash occurred; that's not some sinister MS-thing, just how it works. However, as the wonder full people in audience analytics 'user engagement tracking' and whatnot have spent years exploiting; it's really, really, easy to get additional data on who is following links by programmatically generating unique ones that redirect to the destination, rather than just linking directly.
If the QR code is just "https://support.microsoft.com/en-us/kb/123456" then it makes me want the damn kids to get off my lawn; but it's otherwise harmless. If it eventually ends up at that domain; but starts out as an email marketing standard referrer-slurry URL that redirects you through one or more unnecessary tracking steps before eventually landing you at the URL you were supposed to reach in the first place, that's slimy above and beyond the call of duty.
Oh, as noted, my opinion in particular doesn't matter; it just strikes me as a very bad sign that Apple would manage to release a produce that inspires neither desire nor loathing; but enough lack of interest that it simply fades.
They've struck out now and again; but Apple's strength(in addition to solid industrial design and decent build quality) has always been their combination of willingness to discard the safe bet in favor of what they think is the right one; combined with their track record of being good enough at knowing what that is that doing what they want makes their customers happier than doing what their customers think that they want would.
That's an approach that tends to inspire adoration or howls of outrage. If the response is "Eh, it's pretty impressive that you can get a computer of that power into a watch, isn't it?" it seems as though you have good reason to suspect that you've failed to produce something that captures what has historically made your products successful.
Refusing, rather than carrying out with some enthusiasm and taking pictures, such orders would be a bit of a change in practice; but in the noble land of theory; hasn't it always been the case that military agents are supposed to refuse to carry out unlawful orders(with the obvious practical limits imposed by the fact that most soldiers have access to legal opinion only to the extent that somebody told a JAG to write up a terse summary of the rules of engagement)?
My (admittedly layman's) understanding was that while actually having the issue come up is considered a bad sign(since something has obviously gone badly wrong on the executive or legislative side if the military is being issued unlawful orders); but that while disobeying lawful orders is somewhere between 'disciplinary problem' and 'coup d'etat', depending on how many people are involved and whether they are brought into line internally or not; it is no more a desired outcome for the military to execute an unlawful order than it is for the judiciary to rule according to an unconstitutional law; or the executive to act without legislatively granted authority.
The only real change here is that we have an actually-high-ranked-spook not weaseling around and claiming that waterboarding is just the sort of practical-joking fun that we all did when we joined a frat.
The internet certainly changes 'security' in some ways(eg. this may not be a 'CS' problem; but "you have 1 million users; many of them with room-temperature IQs or horribly malware riddled home computers; you need some heuristics to detect compromised accounts aggressively enough that we don't get blacklisted and the world's major email systems won't touch us; but not so aggressively that we piss off customers with false positives or need to expand our customer service department by a factor of ten" is the sort of security-related question that really only comes up with the scale that the internet allows; and isn't obviously solvable with even the most skilled and rigorous adherence to secure software engineering practices); but, line with the general conceptual confusion, it's not entirely clear why "cybersecurity" is a different thing from "writing correct, robust, software"(which may count as 'CS', may count as 'Software Engineering', depending on the school; but is only different on the internet because your failure to do so will bite you faster, harder, and on a larger scale than it would have pre-internet).
There are operational and systems administration issues that are definitely different because of the internet(since those are in large part about logistics; and scale matters a lot in logistics); but from the perspective of a curriculum somewhere on the continuum between 'CS' and 'Software Engineering'; I'm not really sure how the 'cyber' part becomes relevant. The internet is a mean place because anyone in the world gets a chance to exploit your mistakes; but "understanding what constitutes 'a mistake' in a computer program" or "best practices for not making mistakes even when trying to do things that aren't just toy projects" don't change just because the penalties are swifter and harsher.
I'm certainly not Apple's core market, so I don't expect Tim to be crying into his beer over this; but in what is probably the least-favorable outcome for Apple(and 'smartwatch' in general); I basically don't have any thoughts on it. Depending on how you prefer to phrase it, it's been out for only a year and it has already dropped below even occasional attention without explicit prompts like this one; or it's been out for an entire year and failed to attract much in the way of visible fans, foes, nor has it carved out any niche applications where it is considered an absolute must-have.
Normally, that's not how Apple products work: there is often a sharp and bitter divide between those who love and those who loath; but people care one way or the other. The watch? It's just 'meh.'
I've dealt with Verizon; it's just that I've also dealt with Sprint; which is to Verizon roughly what Yahoo is to Google. That re-calibrates your standards for what a competent-evil telco looks like.
Apparently the older RSA-and-imitators fobs were a bit shaky; so there would be real reason for concern if anyone is still making authentication 'apps' based on it(recording the token's output every 60 seconds for a couple of months to a year, depending on your luck, would be a serious pain in the ass with a hardware token in someone else's possession; but becomes much more viable if the phone OS allows(whether by design or failure) your application to access the display output of another application. Though, as you mention, in the case of 'soft tokens', if you are privileged enough on the phone to be reading over the target's shoulder, you can probably just grab the initialization value directly; and once you have that absolutely nothing distinguishes your cloned token from the 'real' one.
Given that basically everyone with something even resembling an 'ecosystem' is pushing as hard as they can to have users logging into the same services, under the same account, on their phones, computers, tablets, etc. the only real fix is going to involve dropping the pitiful little farce that 'something on your phone' is actually a 'second factor' in any useful sense.
Phones(whether running software implementations of authentication fobs, or using SMS) have never been ideal for the job(software fobs on network connected devices are obviously vulnerable to attack; and SMS could hardly have been designed with less interest in securing the contents of messages); but at least in the dumbphone days there was no particularly good way to correlate the PC you just hacked with the correct phone, must less initiate a push install of some horrid BREW or mini-java-something program to the handset. The user would be pretty screwed if they were going up against a state-level adversary, since those typically have the full cooperation of the telco and thus do have a decent shot at identifying the correct handset and getting access to the SMS traffic sent to it.
Thanks to the vendors' cross-platform ambitions, though, we have the same lousy device security(possibly worse, since the OSes have gotten substantially more complex); but correlating the target PC and the target phone is no longer an intractable business for all but the atypically motivated and well supplied. I doubt we'll see much change, since it's probably still less dreadful than most people's passwords; and it's certainly a lot cheaper than any of the proper 'second factor' options; but it's not really a second factor.
I haven't poked at it in detail; but does slashdot actually misunderstand unicode, or just not care very much? Taking a "your language isn't my problem; and my life is a lot easier in Latin-1" stance my not be terribly cosmopolitan; but it doesn't really represent conceptual confusion.
Unfortunately, aside from the intervening decades having led to surprisingly little progress in deciding what 'CS' should actually include(in the sense of a degree, I assume that academic computer scientists have successfully held the line on the 'no, running windows update is not computer science' issue); people don't even have the decency to provide a cogent definition of what they are fretting about the presence or absence of in a CS curriculum.
'Cybersecurity". Ok, aside from 'cyber' being a denizen of the worst areas of buzzword hell; do you mean "good software engineering practices with regard to sanitizing inputs"? "How to grovel through IDS logs 101"? "How to not fuck up handling cryptographic keys?" "Side Channels and how to be paranoid enough about them"?
As is so often the case, it sounds like somebody needs to solve the problem between the keyboard and the chair before we can even begin to have a meaningful chat about whatever they say the problem is.
Aside from the fact that this will probably be thrown out on some variation of 'because punk kids', even if there is no weightier legal consideration to be used; because this sort of bad attitude will not impress an arm of the judicial branch whose entire existence is devoted to taking patents seriously; do you seriously think that Alexander Reben, a single engineer/artist/MIT Media Lab product has the slightest chance to 'reform the patent system', even if that were is objective?
Doing this requires a relatively tiny outlay for computing resources, some creativity, and some programming abilities. "Reform the patent system" has proven to be a difficult goal even if you possess lobbyists, lawyers, and financial resources somewhere between "one of the top few hundred largest corporations in the world" and "nation state with realistic aspirations to a security council seat".
Nonsense: My 'Apparatus and method for doing stuff to a plurality of things' is totally different, though your pitiful little 'patent' may actually be nothing more than an infringing special case of the matters covered by my patent. See you in court!
I suspect that this initiative will receive harsher scrutiny in terms of 'findable'; purely because of its overt bad attitude(from the perspective of people who treat patents as a serious and respectable business); but it is relatively hard to claim with a straight face that we currently have a situation where attempting to either discover prior art or existent patents you might need to avoid infringing on is adequately practical.
Even major enterprises with substantial legal resources get torpedoed regularly enough that it doens't even amount to news; and there are situations where "Just don't look, you increase your odds of being hit for willful infringement more than you increase your odds of being able to avoid infringement" is sometimes actually good professional advice.
Attempting to construct a 'Library of Babel' and put a stake through either patent or copyright on that ground (while almost certainly technically feasible, PRNGs are handy like that) are more or less certain to be tossed out the moment they hit a court that doesn't appreciate some snide CS punk getting clever; but you hardly need functionally infinite volumes of algorithmically generated garbage to hit the point where 'discoverability' is effectively fictional: we've largely accomplished that ourselves with good, old fashioned, manual labor and the transmutation of the output of our engineers into the strange and domain specific language of our patent lawyers.
There are plenty of fonts available cross-platform(either because they are liberally licensed or because they are considered vital enough or cheap enough that more or less everyone throws them in; but fonts have never been Unicode's problem(their documentation does include examples drawn from one or more fonts, not sure who they use as a supplier and under what terms in order to provide examples; but those are explicitly noted to be non-normative and purely for the reader's convenience).
For the surprisingly messy business of font formats, we have other standards; and when transferring font/color/size and similar formatting information is important(as in any word processing application) the application's file format provides some mechanism for doing that.
We could theoretically blob all this together into one gigantic Ur-Standard; but creating hideously overlarge standards tends not to actually solve anything; it just moves you from a situation with a bunch of standards, only some of which are implemented on a any given platform; to a single standard which is only partially implemented(and always different parts) on any platform; which is basically the same disaster; but with uglier documentation.
It probably doesn't help that, even if there were a canonical-and-MIT-licensed emoji font, UI look and feel is one of the things that all the mobile platform vendors have enthusiastically sought to differentiate themselves on. It's not at all clear that Apple, Google, or Microsoft would be particularly happy if their pet UI's chosen font were interspersed with lowest-common-denominator-identical-across-vendors emoji; given how much attention each has paid to carving out a distinct look. If those vendors actually wanted a cross-platform emoji font; it would have been pretty trivial for them to make it happen: ~1,700 characters wouldn't be something you could get a foundry to do for free; but it would hardly be a crushing burden for the three of them to pay somebody enough to hack together the necessary font and offer it under a free, nonexclusive, license to anyone who wished to include it. That would pretty much be the end of the story.
As it is, though, various vendors have gone their separate ways; and don't even seem particularly interested in trying to emulate one another as closely as copyright law allows(here is a list of the emoji codepoints and their representations, if they exist, on various platforms. Not always even consistent within a given vendor's product lineup.)
With the exception of one time pads(which are mostly too clunky for practical purposes: it's handy that there is a mathematically rigorous way to 'get a rain check' and use the fact that you were able to transmit n bits across a secure channel at some point in the past to secure up to n bits of communication over one or more occasions in the future; but actually having a known-secure channel even once is frequently a luxury you simply never get); they don't make encryption in 'unbreakable', just in 'far too tedious to be usefully breakable'. Did our glorious senators remember to specify that starting a brute force attack when ordered to provide customer data; and promising to deliver the data just as quickly as it becomes ready, does't count as compliance?
It's pretty rich when someone who has seen the stuff that the Senate Intelligence Committee gets glimpses of would actually claim that nobody is above the law.
Of course, this is Feinstein, wicked witch of the west, so of course she would.
There was arguably a case to be made for the one-time adoption of some 'emoji' in line with Unicode's "Sometimes we do horrible things so that even worse legacy standards and nonstandards can die." policy; but the failure to stop there has been a total clusterfuck.
Even good old Plane 0 is riddled with characters that should never have been allowed to exist; but if the Unicode Consortium had taken the principled stance and refused to hand out the codepoints needed to support migration from various legacy encodings, Unicode would probably still be more or less irrelevant in practice. Cleaning up the mess in the Japanese handset market is at least arguably in line with the same approach.
Once that was done, though, leaving open the invitation to turn Unicode in to a clip-art library was an atrocious plan; and bafflingly stupid(especially since the core mission of rendering actual languages is still pretty deeply unfinished once you wander too far from languages that can be handled with the latin alphabet and a few accents and umlauts.)
And it does; within the scope of what Unicode is actually supposed to do,
The problem is every bloody idiot who doesn't understand the 'what Unicode is supposed to do' part. If characters entered on one platform are showing up as different characters on another; you've either got broken software or a unicode problem. If you want absolute certainty that the recipient will see exactly the glyph you associate with a character; you don't have a unicode problem; you want one of those "Image formats" that certain people on the cutting edge of technology are using to encode, store, transfer, and decode things for which visual fidelity is important...
The fact that 'emoji' are still being treated as Unicode's problem, long after the original issue with freaky Japanese legacy handset design has largely been cleaned up, is just so frustrating. If you want your stupid clip-art to reach the recipient intact, we have a variety of (mature and widely adopted) options for that. Full ICC support and absolute color fidelity? Probably not; but good enough? Sure. Stop trying to turn Unicode into the world's most dysfunctional image format!
That's a bet I wouldn't touch. I wouldn't trust Yahoo to strategize out of a paper bag; but sheer incompetence helps make any attempts at overt malice somewhat self limiting. Verizon, unfortunately, is amply evil and not bumbling enough to stop themselves. br>
Plus, if anyone can outdo Yahoo's garish.com bubble era UI designs, it'd be the terrible human beings behind Verizon's flay-and-reskin phone UI work.
The trouble trouble with the app-based '2 factor' stuff is that there is a lot more room for non-obvious, automatic, exploitation; rather than just the occasional user deciding to do something questionably sensible.
In both cases you mention, the users were acting in direct opposition to what their admins would want; but the authentication fobs dutifully performed exactly as the users expected them to. They didn't mail themselves to China, or just get caught clandestinely camwhoring.
When the 'second factor' is some shoddy little app running on an internet connected computer along with who knows what else; conveniently correlated to your probably-infected desktop by being logged into all the same 'cloud' services; it's vastly more likely that the authentication token is going to go AWOL without the user doing anything atypically stupid, or even being able to tell.
Implementing a 'secure' token in software on an internet connected computer that also runs god knows what else has always been a shoddy idea; popular purely because it's cheaper than dedicated hardware; and possibly not quite as awful as your average password. It's never been, or even pretended to be, an actually trustworthy approach.
What baffles me is how the Intel x86 atom-based emulator manages to be so sluggish. Assuming you have the correct alphabet-soup of Intel VT-D and VT-X and whatever else they are lasering off half their SKUs more or less at random today, even Intel's fairly tepid desktop parts will quite cheerfully emulate roughly as many guests as you have RAM for. Until you open up the emulator that only needs to emulate some feeble, power constrained, phone-SoC atom part.
I can't get too enthusiastic about the 'lightweight' wars when I'm so spoiled by cheap hardware; but it is worth noting that, unless they've really fixed the hell out of it in this release; Android Studio is about as far from 'lightweight' as they come. Running it is like picking up a decent size chunk of tungsten: you expect it to be heavy; but just how much heavier than you had expected is still a bit of a shock.
You'd think that an SSD, 32GB of RAM, and a 3.4GHz i5 would make starting an IDE containing a blank project at least reasonably fast-ish; but no, minutes later, gradle is still gradling away to itself and the lovely alien-on-every-supported-platform UI is lagging and waiting for it to catch up.
These seem like the perfect tool for producing an impressively dense(and very conducive to lights-out management, if only because the alternative would be absolutely brutal) free-air datacenter cooling mechanism.
You server OEM types use enough underfill to keep the forced air cooling from lifting the ICs off the logic boards, right?
Slashdot Mirror
Speaking of 'harvesting data', it would be interesting to see what sorts of URLs end up showing up.
There are always privacy implications if you want to provide genuinely useful input on why a system crashed, since a crash dump can be very informative indeed about what the user was doing when the crash occurred; that's not some sinister MS-thing, just how it works. However, as the wonder full people in audience analytics 'user engagement tracking' and whatnot have spent years exploiting; it's really, really, easy to get additional data on who is following links by programmatically generating unique ones that redirect to the destination, rather than just linking directly.
If the QR code is just "https://support.microsoft.com/en-us/kb/123456" then it makes me want the damn kids to get off my lawn; but it's otherwise harmless. If it eventually ends up at that domain; but starts out as an email marketing standard referrer-slurry URL that redirects you through one or more unnecessary tracking steps before eventually landing you at the URL you were supposed to reach in the first place, that's slimy above and beyond the call of duty.
I'm just not sure if it'll be a "Come for the dystopian surveillance; stay to enjoy the fraud!" or the other way around...
Oh, as noted, my opinion in particular doesn't matter; it just strikes me as a very bad sign that Apple would manage to release a produce that inspires neither desire nor loathing; but enough lack of interest that it simply fades.
They've struck out now and again; but Apple's strength(in addition to solid industrial design and decent build quality) has always been their combination of willingness to discard the safe bet in favor of what they think is the right one; combined with their track record of being good enough at knowing what that is that doing what they want makes their customers happier than doing what their customers think that they want would.
That's an approach that tends to inspire adoration or howls of outrage. If the response is "Eh, it's pretty impressive that you can get a computer of that power into a watch, isn't it?" it seems as though you have good reason to suspect that you've failed to produce something that captures what has historically made your products successful.
Having a "Top Secret" stamp means never having to say you're sorry.
Refusing, rather than carrying out with some enthusiasm and taking pictures, such orders would be a bit of a change in practice; but in the noble land of theory; hasn't it always been the case that military agents are supposed to refuse to carry out unlawful orders(with the obvious practical limits imposed by the fact that most soldiers have access to legal opinion only to the extent that somebody told a JAG to write up a terse summary of the rules of engagement)?
My (admittedly layman's) understanding was that while actually having the issue come up is considered a bad sign(since something has obviously gone badly wrong on the executive or legislative side if the military is being issued unlawful orders); but that while disobeying lawful orders is somewhere between 'disciplinary problem' and 'coup d'etat', depending on how many people are involved and whether they are brought into line internally or not; it is no more a desired outcome for the military to execute an unlawful order than it is for the judiciary to rule according to an unconstitutional law; or the executive to act without legislatively granted authority.
The only real change here is that we have an actually-high-ranked-spook not weaseling around and claiming that waterboarding is just the sort of practical-joking fun that we all did when we joined a frat.
The internet certainly changes 'security' in some ways(eg. this may not be a 'CS' problem; but "you have 1 million users; many of them with room-temperature IQs or horribly malware riddled home computers; you need some heuristics to detect compromised accounts aggressively enough that we don't get blacklisted and the world's major email systems won't touch us; but not so aggressively that we piss off customers with false positives or need to expand our customer service department by a factor of ten" is the sort of security-related question that really only comes up with the scale that the internet allows; and isn't obviously solvable with even the most skilled and rigorous adherence to secure software engineering practices); but, line with the general conceptual confusion, it's not entirely clear why "cybersecurity" is a different thing from "writing correct, robust, software"(which may count as 'CS', may count as 'Software Engineering', depending on the school; but is only different on the internet because your failure to do so will bite you faster, harder, and on a larger scale than it would have pre-internet).
There are operational and systems administration issues that are definitely different because of the internet(since those are in large part about logistics; and scale matters a lot in logistics); but from the perspective of a curriculum somewhere on the continuum between 'CS' and 'Software Engineering'; I'm not really sure how the 'cyber' part becomes relevant. The internet is a mean place because anyone in the world gets a chance to exploit your mistakes; but "understanding what constitutes 'a mistake' in a computer program" or "best practices for not making mistakes even when trying to do things that aren't just toy projects" don't change just because the penalties are swifter and harsher.
I'm certainly not Apple's core market, so I don't expect Tim to be crying into his beer over this; but in what is probably the least-favorable outcome for Apple(and 'smartwatch' in general); I basically don't have any thoughts on it. Depending on how you prefer to phrase it, it's been out for only a year and it has already dropped below even occasional attention without explicit prompts like this one; or it's been out for an entire year and failed to attract much in the way of visible fans, foes, nor has it carved out any niche applications where it is considered an absolute must-have.
Normally, that's not how Apple products work: there is often a sharp and bitter divide between those who love and those who loath; but people care one way or the other. The watch? It's just 'meh.'
I've dealt with Verizon; it's just that I've also dealt with Sprint; which is to Verizon roughly what Yahoo is to Google. That re-calibrates your standards for what a competent-evil telco looks like.
Apparently the older RSA-and-imitators fobs were a bit shaky; so there would be real reason for concern if anyone is still making authentication 'apps' based on it(recording the token's output every 60 seconds for a couple of months to a year, depending on your luck, would be a serious pain in the ass with a hardware token in someone else's possession; but becomes much more viable if the phone OS allows(whether by design or failure) your application to access the display output of another application. Though, as you mention, in the case of 'soft tokens', if you are privileged enough on the phone to be reading over the target's shoulder, you can probably just grab the initialization value directly; and once you have that absolutely nothing distinguishes your cloned token from the 'real' one.
Given that basically everyone with something even resembling an 'ecosystem' is pushing as hard as they can to have users logging into the same services, under the same account, on their phones, computers, tablets, etc. the only real fix is going to involve dropping the pitiful little farce that 'something on your phone' is actually a 'second factor' in any useful sense.
Phones(whether running software implementations of authentication fobs, or using SMS) have never been ideal for the job(software fobs on network connected devices are obviously vulnerable to attack; and SMS could hardly have been designed with less interest in securing the contents of messages); but at least in the dumbphone days there was no particularly good way to correlate the PC you just hacked with the correct phone, must less initiate a push install of some horrid BREW or mini-java-something program to the handset. The user would be pretty screwed if they were going up against a state-level adversary, since those typically have the full cooperation of the telco and thus do have a decent shot at identifying the correct handset and getting access to the SMS traffic sent to it.
Thanks to the vendors' cross-platform ambitions, though, we have the same lousy device security(possibly worse, since the OSes have gotten substantially more complex); but correlating the target PC and the target phone is no longer an intractable business for all but the atypically motivated and well supplied. I doubt we'll see much change, since it's probably still less dreadful than most people's passwords; and it's certainly a lot cheaper than any of the proper 'second factor' options; but it's not really a second factor.
I haven't poked at it in detail; but does slashdot actually misunderstand unicode, or just not care very much? Taking a "your language isn't my problem; and my life is a lot easier in Latin-1" stance my not be terribly cosmopolitan; but it doesn't really represent conceptual confusion.
Unfortunately, aside from the intervening decades having led to surprisingly little progress in deciding what 'CS' should actually include(in the sense of a degree, I assume that academic computer scientists have successfully held the line on the 'no, running windows update is not computer science' issue); people don't even have the decency to provide a cogent definition of what they are fretting about the presence or absence of in a CS curriculum.
'Cybersecurity". Ok, aside from 'cyber' being a denizen of the worst areas of buzzword hell; do you mean "good software engineering practices with regard to sanitizing inputs"? "How to grovel through IDS logs 101"? "How to not fuck up handling cryptographic keys?" "Side Channels and how to be paranoid enough about them"?
As is so often the case, it sounds like somebody needs to solve the problem between the keyboard and the chair before we can even begin to have a meaningful chat about whatever they say the problem is.
Aside from the fact that this will probably be thrown out on some variation of 'because punk kids', even if there is no weightier legal consideration to be used; because this sort of bad attitude will not impress an arm of the judicial branch whose entire existence is devoted to taking patents seriously; do you seriously think that Alexander Reben, a single engineer/artist/MIT Media Lab product has the slightest chance to 'reform the patent system', even if that were is objective?
Doing this requires a relatively tiny outlay for computing resources, some creativity, and some programming abilities. "Reform the patent system" has proven to be a difficult goal even if you possess lobbyists, lawyers, and financial resources somewhere between "one of the top few hundred largest corporations in the world" and "nation state with realistic aspirations to a security council seat".
Nonsense: My 'Apparatus and method for doing stuff to a plurality of things' is totally different, though your pitiful little 'patent' may actually be nothing more than an infringing special case of the matters covered by my patent. See you in court!
I suspect that this initiative will receive harsher scrutiny in terms of 'findable'; purely because of its overt bad attitude(from the perspective of people who treat patents as a serious and respectable business); but it is relatively hard to claim with a straight face that we currently have a situation where attempting to either discover prior art or existent patents you might need to avoid infringing on is adequately practical.
Even major enterprises with substantial legal resources get torpedoed regularly enough that it doens't even amount to news; and there are situations where "Just don't look, you increase your odds of being hit for willful infringement more than you increase your odds of being able to avoid infringement" is sometimes actually good professional advice.
Attempting to construct a 'Library of Babel' and put a stake through either patent or copyright on that ground (while almost certainly technically feasible, PRNGs are handy like that) are more or less certain to be tossed out the moment they hit a court that doesn't appreciate some snide CS punk getting clever; but you hardly need functionally infinite volumes of algorithmically generated garbage to hit the point where 'discoverability' is effectively fictional: we've largely accomplished that ourselves with good, old fashioned, manual labor and the transmutation of the output of our engineers into the strange and domain specific language of our patent lawyers.
There are plenty of fonts available cross-platform(either because they are liberally licensed or because they are considered vital enough or cheap enough that more or less everyone throws them in; but fonts have never been Unicode's problem(their documentation does include examples drawn from one or more fonts, not sure who they use as a supplier and under what terms in order to provide examples; but those are explicitly noted to be non-normative and purely for the reader's convenience).
For the surprisingly messy business of font formats, we have other standards; and when transferring font/color/size and similar formatting information is important(as in any word processing application) the application's file format provides some mechanism for doing that.
We could theoretically blob all this together into one gigantic Ur-Standard; but creating hideously overlarge standards tends not to actually solve anything; it just moves you from a situation with a bunch of standards, only some of which are implemented on a any given platform; to a single standard which is only partially implemented(and always different parts) on any platform; which is basically the same disaster; but with uglier documentation.
It probably doesn't help that, even if there were a canonical-and-MIT-licensed emoji font, UI look and feel is one of the things that all the mobile platform vendors have enthusiastically sought to differentiate themselves on. It's not at all clear that Apple, Google, or Microsoft would be particularly happy if their pet UI's chosen font were interspersed with lowest-common-denominator-identical-across-vendors emoji; given how much attention each has paid to carving out a distinct look. If those vendors actually wanted a cross-platform emoji font; it would have been pretty trivial for them to make it happen: ~1,700 characters wouldn't be something you could get a foundry to do for free; but it would hardly be a crushing burden for the three of them to pay somebody enough to hack together the necessary font and offer it under a free, nonexclusive, license to anyone who wished to include it. That would pretty much be the end of the story.
As it is, though, various vendors have gone their separate ways; and don't even seem particularly interested in trying to emulate one another as closely as copyright law allows(here is a list of the emoji codepoints and their representations, if they exist, on various platforms. Not always even consistent within a given vendor's product lineup.)
With the exception of one time pads(which are mostly too clunky for practical purposes: it's handy that there is a mathematically rigorous way to 'get a rain check' and use the fact that you were able to transmit n bits across a secure channel at some point in the past to secure up to n bits of communication over one or more occasions in the future; but actually having a known-secure channel even once is frequently a luxury you simply never get); they don't make encryption in 'unbreakable', just in 'far too tedious to be usefully breakable'. Did our glorious senators remember to specify that starting a brute force attack when ordered to provide customer data; and promising to deliver the data just as quickly as it becomes ready, does't count as compliance?
It's pretty rich when someone who has seen the stuff that the Senate Intelligence Committee gets glimpses of would actually claim that nobody is above the law.
Of course, this is Feinstein, wicked witch of the west, so of course she would.
There was arguably a case to be made for the one-time adoption of some 'emoji' in line with Unicode's "Sometimes we do horrible things so that even worse legacy standards and nonstandards can die." policy; but the failure to stop there has been a total clusterfuck.
Even good old Plane 0 is riddled with characters that should never have been allowed to exist; but if the Unicode Consortium had taken the principled stance and refused to hand out the codepoints needed to support migration from various legacy encodings, Unicode would probably still be more or less irrelevant in practice. Cleaning up the mess in the Japanese handset market is at least arguably in line with the same approach.
Once that was done, though, leaving open the invitation to turn Unicode in to a clip-art library was an atrocious plan; and bafflingly stupid(especially since the core mission of rendering actual languages is still pretty deeply unfinished once you wander too far from languages that can be handled with the latin alphabet and a few accents and umlauts.)
And it does; within the scope of what Unicode is actually supposed to do,
The problem is every bloody idiot who doesn't understand the 'what Unicode is supposed to do' part. If characters entered on one platform are showing up as different characters on another; you've either got broken software or a unicode problem. If you want absolute certainty that the recipient will see exactly the glyph you associate with a character; you don't have a unicode problem; you want one of those "Image formats" that certain people on the cutting edge of technology are using to encode, store, transfer, and decode things for which visual fidelity is important...
The fact that 'emoji' are still being treated as Unicode's problem, long after the original issue with freaky Japanese legacy handset design has largely been cleaned up, is just so frustrating. If you want your stupid clip-art to reach the recipient intact, we have a variety of (mature and widely adopted) options for that. Full ICC support and absolute color fidelity? Probably not; but good enough? Sure. Stop trying to turn Unicode into the world's most dysfunctional image format!
That's a bet I wouldn't touch. I wouldn't trust Yahoo to strategize out of a paper bag; but sheer incompetence helps make any attempts at overt malice somewhat self limiting. Verizon, unfortunately, is amply evil and not bumbling enough to stop themselves. .com bubble era UI designs, it'd be the terrible human beings behind Verizon's flay-and-reskin phone UI work.
br> Plus, if anyone can outdo Yahoo's garish
The trouble trouble with the app-based '2 factor' stuff is that there is a lot more room for non-obvious, automatic, exploitation; rather than just the occasional user deciding to do something questionably sensible.
In both cases you mention, the users were acting in direct opposition to what their admins would want; but the authentication fobs dutifully performed exactly as the users expected them to. They didn't mail themselves to China, or just get caught clandestinely camwhoring.
When the 'second factor' is some shoddy little app running on an internet connected computer along with who knows what else; conveniently correlated to your probably-infected desktop by being logged into all the same 'cloud' services; it's vastly more likely that the authentication token is going to go AWOL without the user doing anything atypically stupid, or even being able to tell.
Implementing a 'secure' token in software on an internet connected computer that also runs god knows what else has always been a shoddy idea; popular purely because it's cheaper than dedicated hardware; and possibly not quite as awful as your average password. It's never been, or even pretended to be, an actually trustworthy approach.
What baffles me is how the Intel x86 atom-based emulator manages to be so sluggish. Assuming you have the correct alphabet-soup of Intel VT-D and VT-X and whatever else they are lasering off half their SKUs more or less at random today, even Intel's fairly tepid desktop parts will quite cheerfully emulate roughly as many guests as you have RAM for. Until you open up the emulator that only needs to emulate some feeble, power constrained, phone-SoC atom part.
Then. Then you wait. A lot. This seems strange.
I can't get too enthusiastic about the 'lightweight' wars when I'm so spoiled by cheap hardware; but it is worth noting that, unless they've really fixed the hell out of it in this release; Android Studio is about as far from 'lightweight' as they come. Running it is like picking up a decent size chunk of tungsten: you expect it to be heavy; but just how much heavier than you had expected is still a bit of a shock.
You'd think that an SSD, 32GB of RAM, and a 3.4GHz i5 would make starting an IDE containing a blank project at least reasonably fast-ish; but no, minutes later, gradle is still gradling away to itself and the lovely alien-on-every-supported-platform UI is lagging and waiting for it to catch up.
These seem like the perfect tool for producing an impressively dense(and very conducive to lights-out management, if only because the alternative would be absolutely brutal) free-air datacenter cooling mechanism.
You server OEM types use enough underfill to keep the forced air cooling from lifting the ICs off the logic boards, right?