Yup, although who knows when/if ever shared hosting adds support for that, too. Still, at least it's something, that's true…
979 karma · joined March 23, 2018
Reminds me of that Burkiss Way sketch where somebody wants to book tickets to a West End show, but they all involve the spectators being poked in the eye with a pencil:
https://www.buttercookie.de/The%20Burkiss%20Way/Transcripts/...
Still somewhat more expensive than petrol cars in the same category, though.
(Even for a fully self-hosted system you'd still have to figure out how to interface the certificate renewal mechanism with your DNS provider, so not as easy to set up as individual certificates for each subdomain.)
Depending on whether the respective kernel supported it, you were still unofficially able to switch removable SD cards into mass storage mode (though only with a rooted phone), although somehow, even if I remembered to officially unmount the SD card from Android first, it somehow still often led to mild filesystem corruption (luckily never anything fatal, though) that required regular chkdsk-usage.
> Or they could have figured out a new version of MTP that supports basic features like concurrent access and normal metadata. Or they could have gone for SMB/NFS over a virtual network link.
My current phone no longer supports the above mass storage mode-hack for the removable SD card, which annoyed me enough that I actually wrote my own SMB server app (https://github.com/buttercookie42/SimbaDroid), because all other SMB servers for Android that I'm aware of were either outright broken, unsupported, buggy or fiddly to use. Sadly the only open source Java-based SMB server only supports SMBv1, so you're stuck with that, and you still need root for full comfort, but within those limitations it works quite nicely.
On top of that, there's the problem that it's physically impossible to run competing services at exactly the same time. This means that for customers with schedule constraints (i.e. you need to arrive somewhere specific by a certain time at latest), competition becomes much less effective, because you're no longer able to freely choose among the competing operators, but are instead forced to simply take the train that arrives at the right time.
A similar thing is for journeys that involve changes of trains – it's physically impossible to have attractive connections (i.e. without hanging around the station for ages) between more than one or at most (if that) two operators per route, because trains running along the same line always have to be separated by at least two or three minutes.
With air traffic it's different. While airport and air space capacity isn't quite unlimited, it's still not as limited in the way a mixed traffic railway is. Plus a much higher proportion of air traffic is holiday traffic and other long-distance journeys where even a few flights per day would be considered frequent service, so competition is much less limited by that fact.
But that tendering is just internal between the state and the operator – fares and service levels on the other hand are set by TfL (and probably also the DfT to some extent, especially on the GEML and GWML sections).
Did it?
https://en.wikipedia.org/wiki/File:GB_Rail_Subsidy,_1985-201...
paints a slightly more complex picture.
And despite privatisation, a national fare system with through ticketing between operators was maintained.
Only if you discount the infrastructure subsidies, I think.
If you maintain a road to track standards, it's likely also just as expensive. (Definitely not cheap, because an intensive bus service will hammer a road quite nicely.)
Plus maybe another legitimiate niche in developing countries where drivers' salaries are cheaper relative to capital investments cost.
I don't think that's quite true. AWS is rudimentary, true (only forces acknowledgement of warning signals, but otherwise no speed supervision, braking curves or trainstop functionality), but AFAIK deployed almost everywhere, the only major exception I'm aware of being some complex but slow-speed station layouts.
And TPWS… while it doesn't do everything that a truly modern train protection system could do, together with the British practice of long enough overlaps (i.e. an additional safety distance beyond a stop signal that needs to be kept clear, too, in case of an overrun) it's still quite reasonably effective at preventing dangerous overruns. And its deployment has been indeed more gappy, but AFAIK junctions and major speed restrictions, where the biggest risks are, are still quite comprehensively fitted. The biggest gap are automatic signals on the plain line, but then again there haven't been many accidents at those.
> If I remember correctly they do not even have something as basic as an electronic coursebook - which became mandatory in Germany in the 90s already.
Part of that goes a long way back. One of the most fundamental differences is that the UK still does route signalling, whereas Germany completely switched to speed signalling at the beginning of the 1930s.
Route signalling means that the signals indicate the route the train will take, but not the exact speed, so if you want trains to operate safely but without excessive dawdling, route knowledge is a must.
Whereas with speed signalling, the signals directly indicate the safe speed for proceeding, so route knowledge, while still useful and necessary for other purposes, is no longer quite as crucially relevant. Consequently, in the UK ad-hoc diversions without route knowledge are quite taboo, whereas in Germany, emergency diversions due to short-notice incidents are mostly (except for some specific lines with more complex requirements) allowed, albeit with a speed restriction of 100 km/h.
I think it was mentioned somewhere else that that account type would require manually authorising each individual installation, so it'd still be useless for small freeware developers, who are only in it for the fun, too, but want to give away their software to everybody who might find it useful.
> Your QR reader requires no media permission if it uses the standard file dialogs. Then it can only access files you select, during that session.
On the one hand, yes, good point, but it runs into the usual problem with strict sandboxing – it works for the simple default use case, but as soon as you want to do more advanced stuff, offer a nicer UI, etc. etc. it breaks down.
E.g. barcode scanners – yes, technically you could send a media capture intent to ask the camera app to capture a single photo without needing the camera permission yourself, but then you run into the problem that maybe the photo isn't suitable enough for successful barcode detection, so you have to ask the user to take another picture, and perhaps another, and another, and…
So much nicer to request the camera permission after all and then capture a live image stream and automatically re-run the detection algorithm until a code has been found.
So interesting as a fun exercise, but not really useful for probably quite a few apps.
The new attestation system Google introduced recently (which I think also more strongly forces hardware-based attestation for phones that support it and is therefore more difficult to bypass) actually does that – the very highest attestation level requires running a security update not older than one year if I remember correctly.
What remains to be seen how much that'll get used in practice – users with rooted phones or custom ROMs are rare enough that a lot of vendors seemingly have no qualms excluding them, whereas users with outdated phones are probably a somewhat more sizeable number.
And at the same time, the target audience interested in installing a custom Android fork would be much smaller than the potential target audience for F-Droid in its current form.
(Also, for the time being, a much more minimally invasive and less resource-intensive approach would be some sort of Shizuku-like approach, i.e. using the ADB network interface originally intended for wireless debugging.)
That idea already exists and is called Shizuku. You don't even need another phone, because ADB also has a mode for wireless debugging via the network, so you can just use that to locally connect to the ADB daemon running on your own phone.
The Apple situation is still significantly worse than ADB, because (at least without a paid-for developer account) AFAIK you're limited to a certain number of in-development app that you can install simultaneously and you definitely need to reinstall them every few days. ADB currently has no such restrictions.
I don't think Google does the more invasive bit of stripping out non-applicable code protected by API level checks (Build.VERSION.SDK_INT), and otherwise, the simple splitting up of native libraries by ABI, graphics resources by display density and string resources by language (plus any additionally defined code modules for on-demand download of optional features) could have been done wholly locally, too, including signing.
The Digitale-Dienste-Gesetz (https://www.gesetze-im-internet.de/ddg/__5.html) in § 5 imposes this requirement on "geschäftsmäßige, in der Regel gegen Entgelt angebotene digitale Dienste", i.e. "services operated in a business-like manner, usually against payment". The key word here is "geschäftsmäßig" (literally translated "in the manner of a business", "business-like"), which within German law is held to be a weaker requirement than "gewerbsmäßig", that is "commercial".
"Geschäftsmäßig" can be anything you keep on doing regularly, independently of any profit motives – you can find a few discussions of that online, and amongst other things, the same term was also used in now-overturned legislation against commercial assisted-suicide, where it caused the same interpretation problems whether doctors or non-profit associations nonetheless might be construed to be acting "geschäftsmäßig" even if they didn't take any payments.
The "usually against payment" bit means that anything done for money can unambiguously by default be presumed to be business-like (and even worse, one possible additional interpretation is that anything other people usually do for money can be argued to be "geschäftsmäßig", too, even if you yourself offer it for free), but the reverse isn't necessarily true. Keeping with the F-Droid sphere for example, something like https://android.izzysoft.de/ I think could (even if you subtracted the few affiliate ads) very well be argued to be operated in a business-like manner, since it's relatively big and professionally-done enough.
The other relevant law is the Medienstaatsvertrag (https://www.die-medienanstalten.de/fileadmin/user_upload/Rec...), where an exception from the imprint requirements in § 18 is made only if operated for "persönlichen oder familiären Zwecken", i.e. for "personal or family purposes". (And journalistic offerings, which can potentially cover some blogs or forums for example, are even subject to extended imprint requirements.)
The "family" bit is relatively clear, but "personal" purposes are once again more interpretable. A wide reading of "personal" would indeed cover all sorts of non-commercial hobby pages, though in that case you could ask yourself the question why a separate exception for family purposes would then still be required, too?
A narrower reading of "personal" on the other hand would only cover stuff that's literally only intended for you, like login pages to your personal webmail or Nextcloud instances, your private picture or file hosting and similar things. Some lawyers even go as far as including a private diary (that for some reason however you decide to publish online and even without password protection) within the category of "personal" things (though depending how much your diary refers to identifiable outside entities, it could also be construed to be a journalistic offering and therefore definitely subject to imprint requirements), but that's about the limit.
Hobby pages intended for the non-specific general public (outside of just family and friends) are therefore very much in a grey area as to when exactly the imprint requirements are starting to become applicable even if you don't do any ads at all.
.aab-files don't ever make it to devices, they're just for transporting the app from the developer's system to Google for further processing and then pushed back out to devices as regular .apk files (albeit indeed split up across multiple files).
> won't necessarily be loadable on another device since it could have different configurations/hardware that happen to limit it.
For the purposes of independently archiving apps it is a bit annoying, sure, but the only hard dependency is having the correct CPU architecture for apps containing native code, and in practice almost everything runs on ARM, with only the 32- to 64-bits-transition providing some potential roadblocks. (Or I suppose if you wanted to run an app taken from a phone on an x86-based emulator.) Otherwise, you'll "only" be missing additional languages and display densities for graphics resources, but the system already needs to be able to fall back to whatever language and graphics resources are available in case the developer didn't even include them in the first place.
Plus for a while Google itself had a feature in the Play Store that allowed sharing free apps to nearby devices via Wifi, including apps with split APKs. (Though I never tried it in practice and it seems that last year they removed that feature again, so yeah…)
> We can have secure and user friendly compute, both in our desktops, and in all our devices.
I'm doubtful about that, e.g. basically all existing file system sandboxing implementations that I'm aware of tend to break workflows that are more complex than "open exactly the one single file the user selected". (Apple's implementation tries a bit harder, but you still run into limitations pretty quickly.)
E.g. when I open an image in my favourite image viewer, I don't just want to view the one picture I've opened, often enough I also want to browse through other pictures within the same directory without having to explicitly open all those other images through some OS-secured gateway. And even that isn't enough, because my favourite image viewer also has the nifty feature of being able to quickly switch into a different directory (plus it has its own built-in thumbnail directory browser), so ultimately the only way to use its full functionality is through full file system access.
Or videos – subtitles are often enough stored in separate files, so a video player will want to look for those files, too, when it starts playing a video. Split-up archive files work along the same lines, too.
And never mind things like both HTML or DWG files, both of which can reference arbitrary other files up and down the directory hierarchy which need to be loaded at the same time, too…
Now the OS can't be expected to know about the peculiarities of each and every file type, plus you can't make permissions dialogues arbitrarily complex, either, which leads you back to the dilemma of ultimately either breaking more complex workflows, or else having to provide an escape hatch that then promptly runs the risk of getting abused by malicious actors, too.
They can already target malicious apps via Play Protect, including presumably all apps signed by the same signing key, so from that point of view no change would be needed. What this is presumably supposed to achieve is rather making it harder to rotate your signing key after it has been burnt…
Technically not as long as the fallback PDF version remains available.