altfredd

Facebook and Twitter timelines are bad examples. There is no reason to avoid indexing by date and those services do in fact index by date. Those services may even be able to use custom database engines and build excellent date-based pagination menu from their index — they just don't do it. Infinite scrolling has better user retention (read: "takes more time to navigate") and allows to easily inject advertizing. So Facebook and Twitter will continue to use it regardless of it's technical merits.

The article does not make a point to avoid feature-rich pagination. It is not about infinite scrolling somehow being a great thing either. It is about SQL "OFFSET" operator being a piece of donkey shit. SQL requires OFFSET to have precise starting position and that position can only be determined by iterating over first OFFSET items from database — which generally does not use index. Most backend programmers have no clue and try to use OFFSET as their go-to pagination tool. Their pagination sucks and makes servers hang under trivial load.

Unfortunately, the "so long as they are stable" constraint is incompatible with idea of mutable database backend. SQL pays massive performance price for OFFSET and it's results are still neither fast nor stable.

eval() has no economic purpose. It hasn't been removed by browsers purely because that would break backward compatibility.

Non-same origin Javascript does not have economic purpose either. I believe, that it will be completely eradicated from browsers within this century (if not in couple of decades).

That's a bold demand, considering that majority of free games in Play Store monetize themselves via partner installs. For all we know, developers of involved apps are paying a "legit" advertising company for installs, and malware authors act as ordinary partners of that company (likely using a bunch of throwaway accounts).

I imagine, that ASLR uses get_random_u32(), because it is needed during earliest phases in boot, before random pool is initialized. It might not necessarily be the proper function for making kernel random numbers — rather such function might not exist in Linux yet.

The problem with creating such wrapper function is that someone like systemd/Wireguard developers will doubtlessly exploit it to drain entropy pool (whatever that means), at which point kernel drivers may start locking up, waiting for more entropy to appear.

In comparison get_random_u32() is safe to call at any point — including early boot — and does not affect global entropy pool. At worst it may return low-quality numbers, but that can be easily fixed by running your own peudo-random generator on top of it (which is a good idea anyway because you don't want your kernel module to contend with other parties for RNG ownership).

> If those supervisor cores want, they can literally just tamper with the entropy in your pool directly

Go ahead and try to tamper with that pool. On all existing and future kernel versions. After undoing kASLR.

Not arguing, that it is impossible, but malware writers usually choose easier paths. When Samsung backdoored their phones [1], they didn't make a pure TrustZone rootkit. Instead they created a companion app, acting as helper for performing high-level tasks within OS bounds. Intel ME rootkit has it's own network stack and can use Intel network card, because it is both easier and safer than trying to interact with constantly updating OS, written by different people.

A rootkit, trying to perform any kind of complex interactions with host OS, may be exploited and taken advantage of, — for example see bugs [2] in AMD's PSP, that allowed host OS to take over by giving it specially crafted certificate.

[1]: https://www.zdnet.com/article/backdoor-in-samsung-galaxy-dev...

[2]: https://seclists.org/fulldisclosure/2018/Jan/12

I don't like the stated justifications for enforcing telemetry — even if it is genuine, it is basically self-deception.

In my experience, access to analytics is a quality of life improvement for programmer, that does not actually result in better products. Having a thousand times more crash-reports wont's cause your employees to grow extra hands and brain-cells to act on all of them. Having a great insight in user behavior does not automatically translate in great managerial decisions.

Personally I would love Gitlab to stop overusing Javascript and fix performance of their backend instead of trying to conceal issues by refusing to show big files and abusing lazy-loading. But judging by their recent actions, they are more likely to copy more anti-features from Github than work on actual hard problems.

And then they removed "Hot Network Questions" altogether (replaced them with "Network Questions, Manually Featured by Moderators"). And then all of moderators left. Wow.

Java support all sorts of memory barriers via VarHandles (see GET_OPAQUE/SET_OPAQUE). VarHandles can be created from contents of ByteBuffers:

https://docs.oracle.com/javase/9/docs/api/java/lang/invoke/M...

Hey, we have just gotten a enormous phone directory for free! Why are you complaining?

It appears, that FB app indeed uploads copies of specific system files: https://twitter.com/wongmjane/status/1167463077748436993

At first glance, the amount of damage being done is close to nil — even if they reverse engineer received files to steal trade secrets therein (lol), it is hard to pinpoint specific amount of harm, dealt to the copyright owners.

But actually... why are Facebook people doing that? If I were to wager a guess, Facebook needs those files to create exact copies of user systems to debug. In other words, they are trying to save up on buying real devices for their test lab! Using "pirated" copies of libraries to spin up testing VMs is most likely cheaper than owning lots of real smartphones with all available firmware versions. And also illegal.

I wonder if they gauged possibility of being sued for this along with possible legal expenses and found that it is still cheaper than buying those devices themselves.

That depends on the person, who tracks attendance.

If the teacher sells attendance reports (together with detailed lesson transcripts and audio recordings) to Google, Amazon, Netflix, US and Russian governments, all major data brokers and The USA Association of Rich Pedophiles, all at the same time — yes, there is no difference. Otherwise there is a substantial difference.

It is amazing, that a person, directly reporting such detailed information to elsewhere, would be considered a pervert and criminal, but using an automated camera to do the same thing is somehow alright?!!

The description of A2 standard features sounds very similar to the new Linux multi-queue block device framework.

From quick look at latest Linux source code, there are couple mentions of "blk_mq" in drivers/mmc, but there seems to be no actual support for multiple queues (unlike e.g. in drivers/nvme).

Does anyone know, if those are supposed to be same things? Does SD driver actually need new firmware to support multiple queues or is it something, that can be implemented on kernel side in software only? At the very least, it might be possible to use a third-party reader as long as it's kernel drivers are updated to take advantage of multiple command queues.

> I see little connection between today's JS frameworks and ActiveX controls.

XMLHttpRequest used to be a popular ActiveX control, that introduced ability to programmatically perform web requests at programmer's discretion. Most modern Javascript frameworks can't be used without such ability.

> It's a webpage built on web standards and designed for web developers.

There are a lot of web standards. XHTML and XSLT are web standards. Server-side rendering is web standard. Being able to save a page with search results and view it online used to be standard.

Some standards are better than others. Some are objectively bad and promote hazardous and error-prone practices. ActiveX is a standard, that was meant to turn Web into platform for running Windows applications. It did so by giving web developers access to powerful programming languages and diverse range of APIs (some of those APIs were a bad idea by themselves). All modern Javascript web frameworks are spiritual successors of ActiveX, and I sincerely hope, that they will end up in the same garbage dump of history where it did.

The idea itself isn't bad, but Google's implementation of it is terrible. Good actors are forced to show security prompts, that literally scream "this application is malware!!". Bad actors enjoy ability to share MAC/IMEI/whatever with each other and skip whole "prompt for irrelevant permission" nonsense. They don't even particularly care about reading hardware addresses — why bother, when you can embed something like fingerprint.js and automatically identify every single device in existence!

If Google does not improve their P2P networking APIs, everyone may end up eventually integrating some Chinese spyware library, because it is the only approach that does not suck (and there is apparently no penalty for doing so).

> Why shouldn't I buy Google's explanation?

Because Google is notorious for coming up with bogus explanations whenever they get caught red-handed. Every month there is a bunch of news articles, where high-ranked Google employee claims to spy on everyone to "protect people from electric pigs", "lower the danger of Confucian Jihad", "enrich e-mail UX with hefty data-harvesting" or something along those lines.

> If an app that uses bluetooth can get my location via beacons or etc., then bluetooth should be wrapped in location privileges.

There is no reason why apps have to be able to "get location from beacons" in order to connect with another phone over Bluetooth. Same for P2P Wi-Fi API — pairing with another device already requires exchanging tokens via graphical dialog with explicit user approval on both devices. Removing ability to read scan results from API would be enough to fix the underlying data leak. Once two devices are paired, they should be able to exchange data without need for any permissions or user actions.

Instead Google forces users to keep Location enabled long after initial connection is made. Even if there is no underlying bad intention, they should be ashamed of forcing such garbage UX upon people.

Scoped storage does not prevent applications from sharing PII with each other. There are already advertising networks, using BroadcastReceivers and ContentProviders to share analytics data — it is simple and does not require individual apps to have external storage access.

To be fair, denying application knowledge of _device own_ MAC address is beyond absurd. If Google really wants that, they should buy their own MAC block, and regularly rotate the addresses within it when network is off.

A lot of Android own APIs (such as Wi-Fi P2P and Bluetooth) are built on implicit assumption, that application developer knows MAC address of device it is running on. Instead of fixing those APIs, Google now requires everyone using them to request Precise Location permission from user _and_ enable a Location Toggle in device settings. This is pure harassment.

> The most active Wayland developers are not only also Xorg developers but have been so for a very long time

Amusingly, I often hear this argument from Wayland proponents. Do they realize, that those very same developers have failed at maintaining Xorg code base and fixing it's bugs in backward compatible way?

To run a project into the ground and wash one's hands of it... is not worthy of endorsement.

12 years ago I considered using Windows. I liked some Windows applications and, above all, I wanted to play games. Windows looked like it was almost there, so I intended to give it another try next year. Then Vista happened.

As of present day I am a happy Linux and Wine user and don't plan on switching to anything else.

What is there not to get? Javascript in browser simply sucks as platform.

1) No memory limits (technically, there is a limit, but it is much bigger than, say, app heap limit on Android)

2) Background tabs can use setTimeout() to indefinitely run code long after user left them

3) Websites can start background processes (Service Workers) without user oversight. Users can't prohibit that or kill them via easily available means.

4) Applications are non-optimized by default, need massive CPU resources for JIT-compilation

5) Rendering a page with five sentences requires executing tons of said unoptimized code.

6) No permission system for majority of things. All important user controls have to come with browser add-ons.

7) Applications can update themselves anytime without user consent

8) Most web apps do not work offline

9) Everything is tied to proprietary web services with overarching surveillance and dodgy EULAs...

> Interesting, so our current method is to do just what you said -- start a foreground service and acquire a wakelock. But we only do it if our network request takes longer than n seconds

This won't work. One of the less documented properties of Doze Mode is it's ability to sever your network connections. It can already be in action before you start downloading message contents. It can also kick in during the download. If you want reliable delivery, you have to take wake lock and enter foreground mode immediately after getting GCM push.

Look up, what is WakefulBroadcastReceiver, and why it used to be necessary. The class itself is deprecated (because implicit broadcasts are largely obsolete), but it shows, how one can miss opportunity to take a wake lock, causing entire application to be caught in deep CPU sleep. Google promises, that GCM will bring you out of Doze Mode, but I am not sure, if that also applies to wake lock. Your app may be sleepy because of failure to timely take wake lock, causing it to miss time window when Doze is temporarily lifted by GCM.

If you receive "actual contents" separately from GCM ping, you are probably being hit by Doze Mode. Doze is disabled for foreground Services, so your best bet is starting a foreground Service (via startForegroundService) _and_ taking wake lock (from within foreground Service, after your app is considered fully foreground).

Historically Android devices used to sleep by entering low-power CPU mode (sometimes complete with low-power radio and WiFi modes). In that mode all apps and kernel are heavily CPU throttled to the point when you can get network timeout because kernel TCP stack can't send packets fast enough. This is what gets disabled when you take a wake lock.

Doze Mode throttles individual apps by moving them into low-priority cgroup. In effect Linux kernel hardly ever schedules your process anymore. Doze Mode is not disabled by wake locks, only by starting a foreground Service.

Both Doze Mode and low-power CPU mode can coexist, leading to effectively 110% loss of CPU time by your process.

> This new thing is actively lying when you don't use Firebase

It is lying, alright.

That said, I don't think that this lying notification is the best example of Android designers being nefarious jerks. The notification lies to user about non-existing "battery drain", but it only does so when developer tries to get around the requirement to show notification with foreground Service. It is shown when you set notification to be hidden via low-priority. I have also seen it when notification icon was fully transparent. It is basically a retaliation against developer misconduct (when developer tries to run persistent background process without telling user). Ideally, this should encourage developers to show a proper foreground Service notification, which the user may consequently hide via notification settings.

Covert spam?

1) Spammer uses a bot to post harmless automated comments

2) Waits for a while, than looks which of his comments ranks higher in Google

3) Edits some of top-ranked comments to include usual viagra ads with hyperlinks to promoted websites

And spying on people used to be illegal as well.

Now it is going to become legal in Maine — as long as you are an ISP.

> The bill prohibits a provider

Nobody cares, what provider does. What matters is whether or not you sign a damn consent form.

Suppose, that there is a popular mobile App, written by Zhang Li Ltd. The App allows you to buy travel tickets, receive discounts in local stores and upload contents of your address book to it's servers. After a while you notice, that everyone uses it. Your local store no longer sells large amounts of grocery unless you make a reservation from The App. All train tickets must be booked by using The App. A bunch of local utilities stopped accepting payments unless you send them via The App. The thing is just so convenient!

One day you notice, that The App requires you to sign some "consent form" in order to use it's advanced features. A month later it threatens to delete your account if you don't "consent" (of course, it won't say so directly — "our ML algo detected, that you are Russian hacker! plz confirm your identity! account secuuuurity!" — that's how it will roll). The App is absolutely not connected to your ISP — it's authors just want to buy the data, that's all!

Reminds you of anything?

This law sound like it was written by data brokers. It does nothing at best and legitimizes corrupt practices at worst.

WTF is "consent" doing here? Why would ISP ever need to sell someone's data in order to operate? Do they also plan to explicitly prohibit ISPs from torturing customers and selling their organs? From selling illegal drugs to minors? Dear state of Maine, I too would like to waive all my legal liabilities by making my victims sign a bunch of paperwork!