evilDagmar

I don't know about iPhones specifically, but I know I used to sigh and grit my teeth every time I'd debug something networking-related while I was at a public coffee house or something, and there's all those apple laptops, broadcasting the user's registered name on the local network for lord only knows what reason.

They may well be trying to stop something equally stupid happening where someone decided it would be a good idea to blast the user's name and phone number out over the local network.

That's because we don't like telling the people who need to be told that you can sideload apps, because they're the very same people who will later complain that they downloaded a "Free APK" of Sparkle Monkey Defenders eX from some Chinese app store and now their phone is vomiting up full-screen interstitial ads every few minutes. ...and we're supposed to fix it for them.

Have we seen any news about Patrick having a catastrophic aneurysm?

Sweet jesus. I really thought they'd killed this misfeature off after all the shenanigans we had with it in the late nineties.

TL;DR: Your Bluetooth dongle doesn't work because you've plugged it into or right next to a USB 3.0 port which is jamming it to bits. Get any decent USB extension cable and connect it to a USB 2.0 port and everything will be fine.

John Cleese has done how many pieces of architectural art now?

Nonsense. It doesn't take anything more than an old netbook to "optimize" a set of floats that were already arranged as a series of linked coordinates in a couple of seconds. The typical desktop can easily handle several thousands of points in less than the time it takes to punt them across the internet and back.

A full page PDF of text with a few thousand letters specified as TTF outlines prints in realtime on pretty much everything while being rasterized into far more data than the cutting instructions for a plotter with a knife, and Adobe isn't grabbing at wallets for the privilege of doing so.

Actually, yes. They're even good in a classroom because even if a kid screws one up, it's not hard to teach a public school teacher how to re-image an SD card.

You dont hear about it as often because for reasons, the kids aren't exactly encouraged to reach out to adults on the internet. Dogs on the internet and all that.

This seems a bit histrionic. The antivirus industry has for a /very/ long time been a hotbed of stupidity. That's not something Google developed. It also looks like that's where all this nonsense is coming from. Trying to correct it by just calling out Google will get you nowhere. Google bought the company that runs VirusTotal in 2014, but they definitely did not build that monstrosity.

Also, expecting problems of that nature to get wrapped up in just a week is well... "unreasonably optimistic".

You're going to have to start threatening to sue people, because that system is more than a little bit incestuous and definitely does not care. Each antivirus company cares about making the number of detections they can show on their website larger than everyone elses, and that's it.

A few years back a friend of mine put a keygen (from Adobe, no less) and a crack (which was a fix for some incompatibilty I forget) up on his non-SEOd "I don't care" web server so he could more easily get at the files while at work, because he needed them for work. This wasn't piracy, because these were for a couple of long out-of-support products running on hardware you'd be shocked to still see people using (who definitely had the licences but good luck keeping paperwork in order at a rural public school) but he still had to support these museum pieces. Fast forward a couple years and Google eventually indexed his webserver because it was open and someone mentioned it over IRC or something, and then the antivirus engines looked at it, and that's where things went sideways.

The antivirus companies are all in a big rush to show they detect eleventy bajillion more things than the other guy, so several have categories for anything even remotely bad, like keygens and cracks. Most of these are very widely known (especially the keygens that have been around for over a decade) and known to do nothing but spew out a code. The problem here is that since a couple of the antivirus engines now declared these files to be possibly verboten because they might be used for piracy (if you were so cursed as to need decade-old desktop publishing), other, less-granular anti-virus engines now also return a false positive for "malicious software" because they don't distinguish (or care) between the different types of "possibly evil" software. Adding to the confusion is that since a few of these companies use "heuristics" which amount to "If other engines decided this file was evil, then we'll just add it to the Big List o' Evil and call it done." Multiple vendors do this, so over the course of days you'll see more and more engines "decide" the file is evil, and if they know where it came from it gets even worse...

Because now there's more and more "professional" engines reporting "eek! A malware!" of these two fairly innocuous files on this utterly boring dump site running on a BSD server with all of two user accounts, no offsite passworded logins allowed, and a deeply paranoid admin, so the algorithms that are used to determine if a site itself is safe start to drop their ratings... because drumroll please multiple antivirus vendors have begun detecting malware on the site.

Now there's other engines apparently decide that this this site has been getting more and more attention (don't even ask me how the hell this happens other than some people were really bad at copying homework as kids) and the number of virus engines that are "finding malware" on it keeps growing, that it must have been _compromised_. They promptly begin to blacklisting the IP address_it uses, which also happens to vhost a dozen dinky little websites used by church groups and reading circles in a relatively rural community. The idea that it would be compromised is almost laughable because it's barely being allowed to do anything to begin with.

Yet other people going to different vhosts on the same IP address to find out the details about their upcoming church picnic or whatever are now getting dire warnings that the site may have been compromised and it is being used to ship malware so they should turn back for their own safety. This is also about the time anything even attempted to contact the actual admin about the problem, but he's already getting emails from freaked out grandmotherly-types. He's also getting bounce mail reports because some of those anti-virus engines will also declare an email to be malicious just because it came from a "malicious site". This is a pretty spectacular form of madness when you can see that the email which was rejected for "containing malware" was 100% plaintext with no attachments, and written by Mutt and doesn't even have the block of base64 MIME nonsense other HTML-obsessed mail clients do.

So, in short, get some boilerplate together, hit up VirusTotal, and then start tracking down where these idiot antivirus companies are and begin sending your own angry emails to _every single one of them that's reporting a false positive_, because this problem is otherwise never going to go away. The longer they get to sit with bad signatures matching your binaries in your database the further that madness will spread.

Kiss your battery life goodbye then, because HE requires a massive amount of CPU power. So much that it's outright prohibitive for use on a cell phone for at least the next 5-6 years, minimum (Moore's Law)

Google already does what people are spewing apologetics about as justification for Facebook's behaviour, but they do it the right way.

Google's SafetyNet scans the system files, but it looks for _specific_ files that should not be there and ensures that certain files that must remain unaltered actually remained unaltered to ensure that the security model is still intact, so it doesn't need to violate copyright laws by stealing copies of files off the user's phone without permission or user awareness.

...and funny that you mention Windows Defender because it repeatedly advises the user that it might upload files to Microsoft and asks for their approval for doing so at multiple points. Microsoft is being perfectly transparent about what they're doing and giving users the ability to opt-out. They're also the people who make the entire operating system so they've got an obligation to try real hard to prevent another Blaster incident. Facebook just makes a social media app.

You don't need "that version of the system library" to debug anything. If you write decent code that adheres to the published APIs, it works or it's Android's fault. Should it be Android's fault and you deploy a workaround, there's a pretty good chance your workaround will start breaking the moment Android fixes their bug. But this has nothing to do with that.

Let's face it. This is the freakin' Facebook app. It's not doing anything so incredibly revolutionary in the field of computing that requires it to be intimately involved in system libraries. It needs to display cat pictures and take in and emit text and make HTTP and HTTPs calls over the network, oh and monitor the user's every move, even while they sleep.

It's not a fair use exception because Facebook is not the party involved in the copyright agreement. They're a completely separate third party so they don't have any rights at all to those files.

Except it's not the data that's protected by copyright laws. ...and that it's not the original file is what makes it ethically palatable that Facebook is doing this without explicitly notifying the users that it's happening, although they damn well should have because it represents a profound change in the relationship.

Not under US Copyright law, but that's because you have a licence to the software which means you have the fair use right to take this security measure.

Absent a rather dubious user agreement allowing Facebook to copy all the data off your phone, Facebook does not have that fair use right. Nor is it likely even remotely ethical to be doing this without explicitly notifying the user. So, illegal and unethical, but I guess unless some PR firm is paying the news media to be outraged about it, they're not likely to care.

It typically becomes rather "challenging" to justify to management why one shouldn't scrape "aggressively" until the competitor's site degrades or falls over. That's why it's generally kind of sleazy.

Well, you can spend a little time putting some anti-bot measures into place, or you can spend money paying a larger hosting bill for all the wasted CPU time, or you can spend some time explaining to legitimate users why the site fell over under the unwanted load.

The person who started this reply thread repeated part of it twice for good reason. Bots, unchecked, can and do take up a majority of the resources on small to medium sites.

I'd have been much happier with the article if the author had taken a moment to implement a bit of throttling on his end to at least go easy on the remote server.

Then it's a real shame they haven't paid attention to the documentation for NotificationBuilder, because there's a straightforward solution to the problem they're complaining about.

> Problem: The Firebase Android client library is proprietary, meaning FOSS apps can not use it. Apps that do not comply are reported to the user as "using too much battery".

This is simply not true. These two points don't even make a coherent argument, as it's plainly discernible that lots of apps don't use the Firebase Android client library but aren't "reported to the user".

Furthermore, "using too much battery" is not what the notification says. It simply says "is using battery", and even this is avoidable.

Not quite. Apps have always been held to accounting for the amount of battery and clockcycles they use. The only change here is that a notification is now required for an app to deploy a persistent service. If you request the absolute lowest priority for your notification, your app winds up in the list of apps which are "running" in the background (mainly because the stuff way down at the bottom is too easily missed). If you don't request the lowest priority notification, then your notification text says whatever you'd like it to say and your app doesn't feature in the default notification.

...and there are plenty of good reasons to explicitly register as a foreground service.

I agree with you that someone's bound to crank out a GPL-compatible lib for interfacing with FCM sooner or later.

Sounds like an opportunity for someone to sit down and write one. The API and docs for it are fairly palatable and offer some very reasonable guidance on things like exponential backoff.

It still doesn't mean that they're going to be able to go without a persistent notification if they want to run their own background service, but that's a change that everyone is required to deal with. "Secret" background services were abused egregiously by bad actors and sloppy coders alike in the past and it's time for that to stop. This carp some people are floating about it incurring "warning" is nonsense--if they looked at the developer docs they'd see how easy it is to avoid that happening.

This is pretty darned incorrect on a number of fronts. Skipping for the moment that a random histronic Reddit post is being considered "news"...

> "Google started leveraging its de-facto monopoly on Android distributions by forcing all apps to use its proprietary service Firebase for push notifications."

A number of logical leaps of faith need to be made before the word "force" carries any truth, but no one's "forcing" anyone to do anything. A developer can still use the FCM or not, it's up to them. If a developer simply refuses to interface with any sort of proprietary code then it's a wonder they'll touch any commercial product at all (iOS included).

..and since Telegram-FOSS were cited as a source for this mess, here's the very first part of [i]their[/i] statement, which is also not true:

> Since Android 8.0 Oreo, Google doesn't allow apps to run in the background anymore, requiring all apps which were previously keeping background connection to exclusively use its Firebase push messaging service.

Sooo very not true. Android [i]does[/i] still allow apps to run in the background. The developer docs caution against doing so without good reason because so many developers try very hard to ignore the lifecycle methods, resulting in many wasted clockcycles and reduced battery life.

But the Telegram team didn't stop there, so let's unpack the rest:

> Sadly, if the app would set the notification to lower priority (to hide it a bit in the lower part of the notification screen), you would immediately get a system notification about Telegram "using battery", which is confusing and is the reason for this not being the default. Despite Google's misleading warnings, there is no difference in battery usage between v4.6 in "true background" and v4.9+ with notification.

First, it's not a "warning". It's simply a statement. ...and yes, if you're going to maintain a separate push notification service of your own (I'm looking at [i]you[/i], Facebook.) you [i]are[/i] going to be using at least a few clockcycles. There's no way around this.

The backgrounded apps notification is also as "judgement free" as any notification can possibly get. On my phone right now, running Android 8.0... "3 apps are using battery". One of these is my own app (which happens to be a homescreen widget), another is Life360, and another is GSam Battery Monitor. Tap that notification and a list appears, headed up with "Apps running in background" with "Tap for details on battery and data usage" and lists the apps with their icons. Tap one and it shows what resources the app [i]is[/i] actually using. GSAM... 52Mb of RAM, and ~55kB of data in the last month. 0% battery used since last full charge. My app, 0% battery (probably not enough to count as a whole percent) use since last full charge, 5.84MB of internal memory, no data usage. I don't know how other people might view them, but to me these seem like vindications. None of that information is being presented in any way that that should be construed as condemning or accusatory, let alone "misleading".

If Telegram-FOSS doesn't want users throwing a fit about their resource usage, perhaps they should spend a little time grooming user expectations to be more reasonable.

The reddit user who posted this mess, on the other hand... A five-year old account that only occasionally posts anything that doesn't smell of astroturf, and this one post is nearly 80% of their karma. Seems like they've decided to make a foray into outrage-farming.

More specifically, they tend to view it as a cost center that does nothing to increase profits.

Thing #1 to remember if you're in infosec is that you must pitch it based on the money saved by not having expensive problems like having to hire outside consultants and auditors after a breach.

...because there are still bugs being found in the USB handling code that can occasionally be exploited for code execution.

In the US, above a certain size you're basically required to sell off the old hardware because throwing it away counts as polluting, and the people who dispose of exclusively tech stuff charge you for that service.

Those numbers sound a little thin on the bottom, but only a little. Maybe take 15% out of the CIO category and just throw it away, because they're usually very quick to turn on their underlings.

Good luck finding anyone willing to issue you a cert that's valid for 20 years.

Of the two, the regexp from the spec should be preferable, because it is exactly what is in the spec. Some other library would be a once-removed version of it and could actually bring flaws of its own.

Sure, if you don't mind writing garbage code. Otherwise, if you don't understand it, you can't say for sure it's correct, and it's usually wrong.

If we could so readily write this stuff down so that we can come back to it, we could have already banged it in through the keyboard and be done.

What's going on in a good programmer's head is going to be complex and detailed, because we need to understand it to be able to write it, and that basically means we're running the code in our heads before we commit it to a screen.

We're not "setting [ourselves] up for failure". We're solving hard problems with the expectation that we won't have to come back to it in an hour's time just to erase all our poorly planned code and start over. It's not like writing an email--we're switching modes over to thinking like a computer and this requires concentration and focus.