> prompting outrage when there isn't a good reason for it.
Can you expand on why there's 'no good reason for it'?
The equivalent is my peering in your window to see and note down what you rub one out to... every time. And you don't know what I do with that information or where it will leak to.
It is actually not like you peering through his window to see and note down what you rib one out.
It's more like when I have a massive orgy with lots of drugs at my place and I invited a bouncer, who is really good at statistics, to keep track of who is coming in and who are leaving immediately. The bouncer is also keeping track of what each person is doing, and letting me know periodically. And you both are invited for a night of drug fueled insane sex.
From my perspective, I am doing this to make sure everyone is having fun at my party. From the bouncer's perspective, he is there just to collect stats and let me know. He is not there to invade my privacy. I want to do that. I hired the bouncer.
The story is only outrage-inducing because you hired a well-known bouncer whose dayjob - of which everyone is aware - is being a security guard at a mall, observing everyone as they do their groceries and banking.
You are the site owner. The bouncer works for you.
Your users didn't hire the bouncer and don't want to be tracked. Secretly, the bouncer may use this data for nefarious purposes. You can't control how the bouncer will use the data.
Exactly, especially if the bouncer comes to work for you for free. Which is what Google and Facebook analytics platforms do: they are free because they benefit from the collected information in ways beyond your control.
My dads mantra used to be, “if it seems too good to be true, it probably is”. Now, I find I must consistently remind him- if it’s “free” (as in beer, not speech) you’re almost definitely paying for it.
Related, when consuming news, if the story seems to involve ridiculous levels of stupidity or malice, the truth is most likely much more mundane and much more reasonable.
I think that's the broader problem that the article is trying to get at. Pornography is just an example that makes it clearer to people that they should care about it.
No, the equivalent is you walking into a store to buy DVDs, and the store manager keeping a record of what sells well, and what you show interest in, etc. to drive decisions about what to stock next.
> It makes any "video tape service provider" that discloses rental [or sale] information outside the ordinary course of business liable for up to $2500 in actual damages.
It's crazy, we understand that libraries should be barred from handing over our book checkout histories but somehow we allow corporations to do that and much more.
... and then cross-referencing your purchase with everything else you ever purchased. And also every article you ever read. And then selling that information to others.
... and claiming it's not a privacy violation because they don't let the others search for martingoodson, they just offer selection criteria including your age, gender, geographical location, inferred income, inferred religion, inferred skin color, and of course interests.
That analogy only works if its only the store manager keeping the records. Whats really happening is the store manager is outsouring his record keeping to a 3rd party who has full access to the data from his store and data from millions of other stores too.
- the user didn't leave his home
- he has an 'expectation of privacy' because the tracking is covert
- he can't go to a different 'store'... the same covert tracking is in all of them pooling the information
No, the equivalent is you walking into a store to buy DVDs, and the store manager of a nearby store keeping a record of what sells well, and what you show interest in, etc. to drive decisions about what to stock next.
They will just use memcpy_s with the dest len and the len set to the same var. Or strncpy with the limit set to strlen(src) etc. These guys will tell you it's suddenly using 'modern security practices'.
Conversely depending on the code strcpy / memcpy can be 100% safe.
I think these guys are selling static analysis, so they find themselves using these oversimplified metrics... it's a shame because it looks like there was no lack of real issues.
If I ever saw a project where someone wrote a fake wrapper around an insecure function that gave the illusion that it had proper checks in place (which is what's being described here) instead of using the actual function I would be concerned.
And if I ever saw code where the size parameters weren't legit (as in someone used the same variable for both) I would also be concerned unless proper checks where taking place elsewhere. But it is a bad smell.
That's the only point in that particular finding. They did detail other ways in which the whole development standards seem bad.
And, yes, you can always shoot your own foot, but it's still best not to aim directly at it.
ok, so it is exactly the move of someone trying to kill it all from the inside...
But really, it's something easily judged over time. Everyone will be able to judge how our open source attitude is in coming years.
And hay, look, there's more absorption of Linux into Windows... Is that embrace extend, or recognize reality? Or hold on for dear life? From my perspective, it's evolution, and nothing but good.
Once you as a company have a certain track record, I'd say it's not unreasonable for an outsider to shift from "just wait and see if it'll be terrible!" to a more proactive stance. In cases like this, past actions do model future behaviour.
Of course that has never and will never receive any security updates. So although iommu isolation is good, it may not help much if there's a whole other OS hacked that can initiate its own network connections and futz with any traffic, eg, deny main OS updates until it can attack it via an unpatched vuln. TLS is good but it'd only take one hhtp connection through unpatched webview.
The cellular, Wi-Fi / Bluetooth and NFC radios do receive firmware security updates. GrapheneOS isn't going to support devices without proper security support, which includes ongoing maintenance and security engineering / research for the firmware and drivers.
Focusing on the cellular baseband is missing the bigger picture. There are dozens of computers in modern personal computers running their own operating systems. Cellular basebands are very directly comparable to the Wi-Fi SoC. It's a mistake to think that the same things don't apply to Wi-Fi, especially when on so many devices it's much less contained than the cellular baseband. I'd recommend checking out https://googleprojectzero.blogspot.com/2017/04/over-air-expl... which is about exploiting the Wi-Fi SoC older generation device, which then provides full direct memory access since it wasn't meaningfully contained by the IOMMU. It was a configuration and driver coding issue, as the hardware was entirely capable of containing it but was unfortunately not set up to do it.
They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.
AOSP is completely open source. Hardware and firmware is a much different story, but that applies to the device you're promoting just as much...
> They're making good progress and I can't wait to be able to update my handheld device with mainline pieces for as long as anyone who still uses one cares to update it. Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.
What's the relevance?
It's also quite important to note that the Android patch level includes firmware. Purism doesn'tship firmware updates in PureOS as part of it being 'pure', so you would be stuck with the equivalent of an ancient patch level at least with the stock OS. You're also no less dependent on the companies releasing firmware updates.
You're also bringing up hardware as an alternative to an OS that would run on the hardware that you're talking about. It's hard to understand the point. The Librem 5 will be a hardware target for GrapheneOS to consider. It will be missing many of the core hardware security and robustness features, so it couldn't be a tier 1 target, but it could still be unofficially or even officially supported.
If it doesn't depend on any out-of-tree kernel drivers, that will apply to Android and GrapheneOS too. I'm not sure why you're bringing it up as something distinct.
This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements.
I use LineageOS (and have for a while), which is mostly AOSP, and the applications from AOSP today feel older than the ones I used on Google's Android ~5 years ago. As a simple example, Google's Calendar application can create very complicated recurring events while the AOSP one is much dumber.
> Hardware and firmware is a much different story, but that applies to the device you're promoting just as much...
The Librem 5 hardware was specifically chosen so that it contains no firmware blobs and all the firmware is free software and upstream in Linux. There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).
OK, so with AOSP we have a good base to build upon. Why NOT use AOSP to create new FLOSS standard applications? It's certainly less work than having to start from scratch. Besides, there are already some really good free open source Android apps in the F-Droid app store
LineageOS already exists -- if you want an updated AOSP, use that. I'm not sure why folks seem to think that all free software phone projects must necessarily just reinvent the Android ROM.
Android itself has a wide variety of issues which might be solved (or at least solutions might explored) by creating projects that go outside of the mold of Android ROMs.
> AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore.
I want a real Linux in a phone as much as anyone. In fact, I have stuck to the Maemo N770-N9 saga as much as I could.
But I am also realistic. Developing a new secure Linux distribution for phones and, most importantly, a healthy ecosystem with useful applications will take a lot of time and effort.
In the meanwhile, as discussed in other threads here, using AOSP on a Pixel (or even better, GrapheneOS) is a really good solution. It's remarkable how few people use it in comparison to the benefits it brings into the table, and given it's quite easy to migrate to it with the appropriate hardware (hopefully device-independent ROMs make this less restrictive).
If standard applications in AOSP are lagging behind, then it'd be probably worthy to spin off an effort to replicate all proprietary functionality. An equivalent to MicroG.
That said, I've never missed anything major. For me, Firefox/Chromium, K-9, Conversations/Signal, OsmAnd and Termux provide a great userland experience.
> There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).
Interesting, I did not know that. What are the reasons for this? Military application? Are these laws subject to change?
I always thought that there is no way to separate the CPU from the baseband/communications PU.
It's my understanding that the issue is one of FCC certification and licensing -- the FCC won't approve something which can be easily modified to transmit on non-free frequencies (tools which can usually are sold to hamradio license holders, which should know better and know how much trouble they can get into).
>This is only true in the most technical way possible. Yes, AOSP is open source -- but none of the standard applications on any stock version of Android use AOSP anymore. The calendar and other applications are all proprietary. The AOSP versions feel like they stopped being developed in 2010 -- which coincidentally is when Google started developing proprietary replacements.
AOSP sample applications like Calendar are exactly that: samples. I'm not sure why those are at all relevant. There's a very healthy and active open source app ecosystem, along with many other apps that work on AOSP. Those AOSP apps are included as samples, and they're being removed from the project as at this point there's no real need to have these samples.
It's also not true what you claim about the stock applications shipped on a phone like a Pixel. Apps like Dialer, Contacts, DeskClock, etc. are still actively developed and maintained in AOSP with the Google variants being extended versions of those apps. It's true that some apps like the keyboard forked away from the AOSP version, but it doesn't make AOSP any less viable of a basis for an OS. It's not a bad thing for AOSP to not ship a bunch of user-facing apps when there are a bunch of good alternatives outside of it. Apps do better without a release cycle tied to the slower pace of the OS releases.
> The Librem 5 hardware was specifically chosen so that it contains no firmware blobs and all the firmware is free software and upstream in Linux. There is a caveat for the baseband, but that's because it's not legal in most countries to sell or use baseband hardware that is free software (unless the user is licensed and even then it's non-trivial).
This is completely untrue and absolutely a false claim. The SoC is entirely proprietary with proprietary hardware, firmware and microcode along with the other components like Wi-Fi, the baseband, etc. being the same. The cellular baseband is not an exception. It applies to all of the hardware components in general. Librem 5 is not open hardware and does not have open firmware or microcode. It's simply untrue, and you're falsely representing it. I can see why you would be under that misunderstanding based on their incredibly misleading marketing but they never actually claim what you are claiming.
Not providing firmware updates for these things is a security disaster. The firmware that's upstream in Linux is rarely open source. It's a subset of the necessary firmware for most devices and is still proprietary. Projects like linux-libre / PureOS do not ship these upstream Linux firmware updates. They strip all of this out of the kernel. They also don't provide all the additional firmware updates beyond what is upstream.
The hardware and firmware is just as proprietary. The boot chain has open source components near the end before the OS (coreboot), just as many mainstream devices do (https://source.codeaurora.org/quic/la/abl/tianocore/edk2).
There's a huge difference between choosing hardware that has built-in firmware and can work without the OS supplying it each boot and hardware with open firmware... what they are doing is shipping a device that can work without the OS providing firmware updates, since they don't do that to keep it 'pure' of proprietary code. The firmware is still present and running, except it's out-of-date and vulnerable to many patched security vulnerabilities. You're completely misrepresenting the reality and falsely portraying it as having open hardware and firmware when it absolutely does not.
What you claim about not being allowed to have open cellular baseband firmware is also nonsense. It's also not particularly different from how Wi-Fi works. Wi-Fi firmware is a comparable secondary OS, and the same applies to a lot of other components. These hardware and firmware components on the Librem 5 are not any more open. What you're doing is spreading misinformation and false claims to promote it as something that it's not.
Librem 5 isn't going to be particularly security-focused: no attestation, no trusted boot, most userspace programs are written in memory unsafe languages like C, with no extra effort memory corruption mitigations. Also, Flatpak offers a permission system that's very limited compared to Android.
There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing.
In FOSS initiatives spent ages building fee and and open software, combating proprietary systems and software that they had no control over.
All that would be loss just to give it up now that we have moved from PCs to phones....
I for one want control over all the software I run on hardware I own. I am not sure why we are so willing to give that control up simply because the platform changed.
> There is security, and then there is freedom. You can have the most secure system in the world -- but if there are state sponsored, or company back back doors it means nothing.
Okay, so you're saying: "If a backdoor is present than your security prioritization doesn't matter, the result is bad." I understand, but:
1. If there is a back door in open source code that goes unnoticed (and it certainly does) because of persistent but bad practices in the open source community (e.g., a stubborn refusal to stop using C-like memory management semantics and primitives when dealing with untrusted inputs), then why don't said accidentaly backdoors invalidate the open source work?
2. Does "control" actually matter in the context of AOSP? Strictly speaking, you have essentially everything you need up utill you hit the hardware drivers. You can easily rewrite that to your hearts content.
3. Given Librem's recently move into commodity-based social products (and the poop-from-great-height attitude they initially adopted), are you genuinely sure that they're actually trustworthy actors? If they're coerced, how will yu attest that they never injected a deeply subtle backdoor on millions of lines of code which you'd like to be unique and less scrutinized?
I can't really work out why you feel the way you do, so I ask these questions.
> persistent but bad practices in the open source community (e.g., a stubborn refusal to stop using C-like memory management semantics and primitives when dealing with untrusted inputs)
This applies to the entire industry. It's not something specific to the open source community. It's also extreme to call the use of C as "bad practice," as any language has its own strengths and weaknesses.
Not the entire industry, as many companies have thankfully moved on from plain old C, or at very least reduced its use quite considerably.
BSD/Linux derived FOSS is still the C stronghold.
The Morris worm was in 1988, since then C has collected enough CVEs due to memory corruption issues to consider its use bad practice.
Something that even Apple, Google and Microsoft security reports now advise against, and with Google actively engaging into taming C's usage in Linux kernel.
The operating system is only a tiny fraction of commercial code out there most of which is either written in (more) memory safe languages like Java, C# or C++. SAPs code base alone is 1 billion lines of mostly C++ and their own proprietary scripting language.
Not to the extent that it is tainted by C's copy-paste compatibility.
Still it does provide a stronger type system, proper string, vectors, reference paramenters and strong type enumerations, to prevent a large amount of C security exploits.
C++ teams that care about security do use such features and respective static analysers on their CI/CD to enforce them.
While it doesn't cover everything, it is much safer than plain C.
Ideally, we will reach a state where both C and C++ get nuked, or ISO C++ just drops its C copy-paste compatibility, which in the end means it is anyway easier to switch to something else.
However that process will take decades, and is hampered by relying on POSIX based systems.
Desktops are dwarfed by mobiles devices. AFAICT a linux kernel variant is present on most of the world's smartphones (with most of the rest being iOS devices, which I know little about), though you've addressed that by saying Google are pushing to reduce the impact of C underlying their system.
I don't want to make a song and dance about C being awesome or anything - we've certainly got massive issues with allowing that extreme amount of flexibility without ensuring that the developer really, really means what they've just told the machine to do - but it's hardly a small enclave that's holding out, it's still huge.
And there are still companies developing in it. I've seen a sort-of-microservices-in-C-implemented-as-a-sort-of-supersized-cgi-bin approach relatively recently.
Windows Phone, JavaScript, .NET (VB and C#) and C++.
iOS, JavaScript, Objective-C, C++ and Swift, C only due to BSD stuff.
Android, Java, Kotlin, JavaScript, C++, C only due to Linux kernel. Its sucessor. Project Treble drivers use Java and C++. Fuchsia is written in a mixture of Rust, Dart, and C++.
ChromeOS, JavaScript, C++, Rust, C only due to Linux kernel
> Windows Phone, JavaScript, .NET (VB and C#) and C++.
An irrelevance given their complete lack of market presence.
The rest all have significant underlying C components you've identified. All I'm saying is that's a hardly a 'niche holdout' when it appears to be at the heart of the vast majority of shipping devices.
Why do you assume that OSS has more bugs than proprietary software? I would probably argue the opposite.
With OSS you get more people working on a project that actually care. A proprietary business project prioritizes making money over actually creating a good product everyone loves.
You're right that this is not a perfect solution. All software has bugs and all software may have malicious back doors. I just find it much easier to trust the development that happens in the open with community involvement than the development that happens in secret where I have absolutely no way see what's going on.
If you had an inkling that someone was trying to poison you, would you rather eat the food you watched be prepared or the food that was prepared in secret? Both dishes might be poisoned, but it's reasonable to prefer the one you were able to examine.
> Why do you assume that OSS has more bugs than proprietary software? I would probably argue the opposite
I don't. But nor do I assume it has less. My point, as restated elsewhere, is that from a user's point of view Openness of Source is more about protecting against negligence.
Who exactly is talking about anti-openness here? We're talking about which open source piece of code to reuse. Someone gave a bad argument against one company's offering.
Microsoft of the 90s, which no one emulates these days and it's a wrongheaded comparison anyways, would have said that all the open options are bad to begin with.
If you meant to say "anti-free software" then maybe we could have a conversation, but that's hardly the problem Microsoft faced in the 90s and 2ks.
Seriously, what does your post mean? Could you maybe be specific? And while we're at it, what's your connection if any with the company that sells Purism phones.
“Open source is not safer because people won’t read the source”, “having control doesn’t matter”, and trying to raise doubts about the trustworthiness of the people involved... that’s old Microsoft textbook approach.
At least MS wasn’t built on open software, unlike Google.
> And while we're at it, what's your connection if any with the company that sells Purism phones.
None at all. I’ve just heard of this project a few days ago via a DDG search.
Believe it or not, not everyone is a corporate shill.
> Open source is not safer because people won’t read the source
That's not what I said. To sum it up: Open source is not really a security proposition. It eliminates problems related to negligence.
> having control doesn’t matter
In what concrete way does the Purism OS give you more control over your device than AOSP?
It really seems like you are confusing open source and free software for this entire conversation, as literally every line of code we are discussing is shared under a license that allows you to look at, modify and use as you see fit.
> None at all. I’ve just heard of this project a few days ago via a DDG search.
The depth of your consideration was already fairly easy to guess, but thanks for being honest.
> Believe it or not, not everyone is a corporate shill.
Bad software is bad whether it's open or not. But historically, closed software has more lock-in. If a particular open lib or component is bad, it can often be fixed by somebody who didn't create it. Or, for those who don't want to touch the scary hairball, it can often be replaced by a completely new hairball written from scratch by a completely different party. Even if there's nothing broken with the original, open software is friendlier to alternatives. It might take a bit of work, but you can replace one open part with another just because it's shinier or smaller or faster or not Oracle or whatever.
I don't trust all open source software, but I trust it by default more than I trust closed software. And I know that if something really bad gets exposed the odds of a solid fix are better in open source. I get to see the warts of OSS. There's public criticism over small details on a lot of important projects. That doesn't happen for closed stuff. Sure, a vendor may have four of the brightest devs in that field and they might hash it all out behind closed doors. The open alternative usually has another four of the top 12 minds in that field along with four pretty competent others and they have a better process for hashing it out.
Then there's that other guy who's not in the top 12 who goes it alone and comes up with something spectacular. So three of the four from the other open project jump on board because they can. And since this new project tries very hard to be backwards compatible, it just snaps in as an overnight replacement. That's part of the awesomeness of OSS.
I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it.
In some facets, AOSP is not a complete and working OS as is. In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out. Additionally, many (that is, 95%) of all Android apps that you would find on the Google Play store do not function properly without Google services (which AOSP does not have). Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world. They are typically FOSS projects that are built out of passion, but recieve little funding or corporate support.
These shortcomings often carry over to third-party ROMs, such as Lineage.
So in my experience, as someone who used to flash a new Android ROM every week, it is not about freedom - its about basic functionality. One could also argue that, since the world operates on all kinds of propietary platforms that aren't available on stock AOSP, so do we also lack the freedom to use AOSP as our daily driver - simply because it often does not interface properly with these propietary platforms.
In general, until we have open source handset hardware to work with, all fine-tuned sensors and clock hardware support will be bad. This is a problem Linux had for a long time, and it took a ton of effort to partially solve the problem. It seems a bit unfair to blame AOSP for not having drivers for specific hardware, that's not it's function.
The big contribution of Purism phones is that more open hardware. After that, the real question we should ask is, "What software platform can offer us the greatest values in the multi-dimensional optimization problem we face?"
It's true though that you wouldn't just flash AOSP. But it's also true that dismissing Graphene BECAUSE it is based on AOSP is unfair.
I am not meaning to paint those who work on AOSP or third-party ROMs in a bad light. The work they do is terrific and great for the community. I also do not mean to dismiss any of the fantastic work that Graphene brings to the Android community.
I am simply stating that the biggest difference between Librem and Android is that there are more hurdles to jump through to provide a completely usable and free AOSP phone to an end-user in 2019. Android has been made to host a Google ecosystem, where the Librem 5 is being created to host an open ecosystem.
It sounds like the Purism team identified this issue ahead of time and decided to provide that open hardeware platform for us.
Librem 5 is not open hardware. I also don't understand why you're comparing hardware to an operating system that's perfectly capable of running on top of it with the strengths and weaknesses of the hardware underneath it. You make it sound like AOSP or GrapheneOS wouldn't run on it. I don't think it would make a very good hardware target due to having so many security regressions from the status quo but it could certainly be one of the official targets. Whether or not it's an official hardware target, people will be able to use GrapheneOS on it.
strcat, many thanks for your interesting explanations.
Could you write more on the state of open hardware, and perhaps point me to open-hardware endeavours that have the slightest chance of success?
I understand that it is an very expensive undertaking to deliver a hardware mashine that is based on an open architecture from the CPU to the actual communication/data storage devices (logical design, actual layout, photolithography, assembly). Since patents on older circuitry must be all expired by now, it must be the lack of money that is the actual stopper for truly open systems.
PureOS seems to have these exact same problems except way worse.
Yes, a significant fraction of Android apps do not work on AOSP without Play Services. And 100% of Android apps do not work on PureOS. F-Droid alone has ~1800 apps. I do not see PureOS or PostmarketOS catching up to that level anytime soon.
FOSS projects that are built out of passion, but recieve little funding or corporate support? Exact same situation on PureOS.
Are the Snapchats and Instagrams of the world going to port their apps over to this entirely new platform when they can't even be bothered to make versions of their Android apps that work without Google's services?
> 100% of Android apps do not work on PureOS. F-Droid alone has ~1800 apps.
This is a fair point. It's not a huge argument for me because I'm only interested in maybe 20 categories of app and I've never been thrilled with the 30 contenders in each category. For instance, if it has only one browser and that one is Firefox, that will be ok with me to begin with. It won't bother me if there are five other choices in F-Droid. But in general, more choice is good, so I grant that this is an important consideration.
> Are the Snapchats and Instagrams of the world going to port their apps over to this entirely new platform when they can't even be bothered to make versions of their Android apps that work without Google's services?
Android without Google's services is a tiny fraction of Android and a smaller fraction of the whole market. PureOS or anything else with even smaller share can expect to be similarly ignored. But Android sans G seems even less likely to go viral than something else.
For one thing, it's too fractured. There is no AOSP brand. There's a bunch of little no-names that happen to offer AOSP under some name that isn't "AOSP" and has no recognition at all. If two or three lower-tier makers offer "Brand C" phones, it could spark. Maybe not in your neighborhood. But if it catches on in India or Malaysia or Brazil, it might be enough to attract Instagram or Twitter. Remember that those companies don't want to depend on Google. They very much want Google out of the picture.
So a handful of apps can legitimize a new platform that is attracting a million or ten users anyway. Then it becomes perilous not to be on that platform. WhatsApp can't afford to let some up and comer get a foothold just because WhatsApp wasn't available on the viral new platform.
Ahhhhhh. Ok I'm going to quit dreaming for now and get back to work. I'm not holding my breath, but I do think it can happen. It just takes the right lucky timing. There have been so many helps lately that I think if there was something ready to take advantage of these incidents, the timing is right.
> I believe there is a general lack of awareness of what AOSP is without Google services and add-ons on top of it.
That lack of awareness seems to be your own.
> In particular, I have personally had many issues with GPS location for the past fews years. Out-of-the-box, GPS simply does not work without additional non-free software to help it out.
GPS doesn't require Play Services, etc. Play Services provides supplementary network-based location services for providing a coarse, inaccurate location estimate without waiting for a while for a GPS lock. The infrastructure for this is open source and part of AOSP. It has generic, provider-agnostic support for services like supplementary location providers, text-to-speech, speech-to-text, geocoding, etc. Play Services is what provides these on phones with Google Play, but there are alternative implementations used by Amazon and in China.
> Applications that are built to run on stock AOSP are not the 'Snapchats' or 'Instagrams' of the world.
Yet apps like WhatsApp, Facebook's apps, Microsoft's apps, etc. do work without Play Services... despite what you claim. A lot of these mainstream apps do work fine, and there's a large ecosystem of open source apps that are mostly designed to run without Play Services. Providing the Play Services APIs with an alternate implementation and is also certainly possible, although I would prefer a different approach than microG.
How is any of this resolved by moving to a completely different OS with far less privacy and security, none of these mainstream applications you talk about and barely any open source application ecosystem by comparison? I don't get it.
You seem to be off on the state of Google Play Services from a real-world standpoint. Case in point: Microsoft's core apps like Outlook and Skype don't work without Google Play Services enabled, even if you find the APKs somewhere other than the Play Store to sideload them.
Microsoft's apps are specifically an example I've given of how closed Android truly is: Even Google's competitors, which have all of the same service capabilities, are essentially forced to use Google Play Services. Especially when you consider the other top HN item today about how Google now essentially requires all apps use a closed source Firebase library for push notifications.
And while yes, Google Location Services is a location provider that slots into Android, you are missing that Google has convinced app developers to call it directly, rather than using the Android location provider. This means that no alternate location provider will do: Google Location Services is hard coded into almost every location-based Android app today.
If you're willing to make your location known in order to take advantage of location services why wouldn't you want the very best possible service? There are complicated workarounds that can be used in place of Google's location services but none of them are anywhere near as easy to implement for the app developer or as easy to use or as accurate for the end user.
GPS doesn't make your location known at all, it's receiving only. It sends information about your location to nobody, it triangulates your position from publicly broadcast signals.
And, I would much rather "make my location known" to about fifty other companies before I would want Google to have it.
Yeah, GPS is actually insanely cool technology, and the US making it available to everyone was a real public service. Now of course, other nations are, partially for defense purposes of course, deploying similar networks as well.
And it's just out there. Usable with no subscription, no account, nothing. It's just free data.
Notice I didn't specifically mention GPS, although I agree that it is pretty cool. That said, GPS alone isn't capable of providing the UX that end users expect from a modern app. Fused Location is required for more accurate location information and it isn't passive like GPS.
I used CopperheadOS (without GApps) on a Nexus 6P as my daily driver for almost 2 years. Very few "mainstream" apps worked; they would loudly complain about the lack of Google Play Services, and at best would lose functionality (e.g. Slack, which apparently relies on Play Services for notifications) or at worst would crash either immediately or within a few minutes after launch (multiple reasonably-popular online dating apps had this problem).
In short, of the apps I tried that weren't distributed via F-Droid, most of them suffered from varying degrees of brokenness without Google Play Services (and these same apps work fine on my HTC One M8 and my current-daily-driver OnePlus 5T, both of which run LineageOS w/ GApps).
You're right, though, that "some Android apps work fine" is a better situation than "no Android apps work at all". Hopefully GrapheneOS can leverage that advantage well. It'd just be useful to acknowledge that it ain't all sunshine and rainbows just because it's AOSP-based; whether it's microG or something that ain't a security landmine waiting to blow off someone's leg, addressing that issue with an alternative service provider would be a game-changer, and would readily address the one issue I ever had with CopperheadOS (and - it seems - likely would still have with GrapheneOS).
Have you tried a pure AOSP + F-Droid on Nexus/Pixel or Xperia? It's quite good. The only major drawback are closed drivers. But the userland is nice, open and polished.
My worry with Librem and all those initiatives is that rebuilding an ecosystem like F-Droid takes a lot of effort and time.
I primarily used a OnePlus 3 (non-3T) and a Nexus 4. The OnePlus 3 seemed to have a very active ROM community.
I tried many of the well-known ROMs: Lineage, Paranoid, Ressurection.
I also tried many of the OnePlus-specific ROMs, that were typically maintained by only one or two devs each.
Most of the features worked perfectly fine on both phones. But the deal-breakers were often the simple things: GPS (w/o downloading extra geolocation database services) and Bluetooth were the kickers for me. These services were consistently spotty across every ROM I tried.
My experience is as of a couple years ago. I have since moved away from the ROM scene, simply because I do not have the time to deal with this sort of stuff anymore.
A Pixel running stock AOSP with F-droid and Chromium is the bleeding edge of what's possible with open source. There's no better UI/UX in existence and the tragedy of it all is that outside of Android developers and software engineers most people never get to experience it at all.
The reality is that Librem is unnecessary because we have F-droid. There's nothing wrong with F-droid and as time goes on more mainstream apps will continue being brought over.
Too bad the Pixel doesn't have a headphone jack, otherwise I would have bought one. I've also heard it was pagued with hardware issues. Stuck on Nexus 5 + LineageOS for the time being.
GrapheneOS is sadly only available on Pixel devices.
I tried microg's Lineage image on the OnePlus 3. It was probably the most painless ROM I had ever flashed.
The microg project has been fantastic in providing an open mechanism to interface with Google's services. When I first tried it, I believe they did not yet have a working implementation of all the Google services. Some apps complained about Google services, some did not. You still needed to sign into Google though, which might turn some people away.
For those who want to interface with Google on an open-source ROM, microg's image is probably the way for you.
I for one cannot attest how many backdoors this Ubuntu installation might have, and I doubt everyone has the knowledge to validate their complete FOSS stack.
> As such I have a very hard time believing that Librem with be as secure as modern Android.
Android isn't secure, it's limited, that's the whole problem here. Any security you can't control isn't a security feature but just a limitation. It's "secure" because you can't do anything interesting with it.
Using Android with reluntance, since my favourite OSes were Symbian and Windows Phone, additionally I dislike Android J++ and the NDK is relatively constrained.
Still, I can do plenty of interesting things with my Android gadgets.
I guess that's because they know that Chain-of-trust only gets you so far.
Eventually you're running something big with bug after bug found every month and and an attack surface that includes the local filesystem and the network. At that point the buzzwords make no difference.
Chain of trust won't reduce the attack surface, but adopting memory corruption mitigations and replacing C code with something with stronger memory-protection guarantees would -- and while some kinds of memory protection can be bolted on later with minimal disruption, minimizing C is best done from the start.
That sounds reasonable, but here we are with Android's endless security disaster and all their apps written in not-Java from the beginning.
The most cancerous aspects of Android are by design, that you cannot control network exfiltration from apps, you cannot update or modify the OS pieces at will, and the apps are monetizing everything you do and everything they can find against you. Librem will answer these.
> that you cannot control network exfiltration from apps
GrapheneOS has a Network permission toggle, which is one of the features already restored from the past work on the project. There are many other privacy and security features that still need to be ported to the latest release, although a lot of them have become standard features especially in Android Q. https://gist.github.com/thestinger/e4bb344dcc545d2ee00dcc22f... is an overview of the Android Q privacy improvements(not security improvements, just privacy) in the context of GrapheneOS. To conserve development resources, the past features that are becoming standard aren't going to be ported over rather than just waiting for the standard implementations being released around August. Some of them will need to be adjusted to make them a bit more aggressive when it comes to apps targeting the legacy API level, but that's a lot less work than maintaining downstream implementations of all of this.
> you cannot update or modify the OS pieces at will
Having a well-defined base OS with verified boot and proper atomic updates with automatic rollback on failure is a strength, not a weakness. It's the same update system (update_engine) as ChromeOS. The update system is not the problem with the broader Android ecosystem with lack of updates to vendor forks. The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS and it's one of the things that has to be changed downstream to improve verified boot.
> Librem will answer these.
That's nonsense. First of all, that's hardware, and also moving to a far less secure software stack with non-existent privacy and security, an inferior update system and no verified boot is not a solution to these problems. The solution to privacy and security problems is not completely throwing away privacy and security...
>The migration towards everything being apk components that can be separated updated rather than moving more towards the ChromeOS design is a negative thing in terms of GrapheneOS
Doesn't stuff like fs-verity help with stuff like this instead of just a block based RO partition that can be verified ? Overall, for the android ecosystem, it seems like a net gain if google moves more and more stuff out of band away from OEMs as OEMs are not incentivized to do anything other than sell devices. That is, as long as everything is still pushed to AOSP.
Large majority of Android security exploits are in C and C++ written drivers, hence why with each release the amount of freedom with native code gets further locked down.
Chain of trust does protect you from evil maid attacks.
And yes, there can be bugs in application layer, but at least half of all CVEs are memory corruption bugs.
These practices do offer a massive reduction in attack surface. You seem to argue it doesn't matter since it doesn't eliminate attack surface completely.
No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability.
If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way.
Librem's security model is that of a Linux box, signed update packages... it's not a panacea against hacks but nor are the buzzwords you mentioned. At least they're trying to eliminate the really dangerous proprietary pieces that constantly provide new vulns.
> No, chain-of-trust only has one trick... it can check that what you're about to run is unaltered from what was signed to some degree of probability.
This is only one of many privacy and security regressions from moving to a far less secure software stack without anything close to the same level of hardening or work on privacy / security.
> If that is the - shipped and validly signed - bugridden nightmare-fuel like the propreitary Qualcomm 802.11 stack or proprietary multimedia bits that are a rich and continuous source of vulnerabilities (take a look through the last months here https://source.android.com/security/bulletin/2019-06-01 ) all the buzzwords did was ensure the vulnerable version is running so it can be exploited. The evil maid can get in that way.
Counting CVEs is not a way to judge security. Qualcomm's SoC hardware, firmware and driver security is the leader among the available options. The huge amount of both internal and external public security research targeting it is a strength rather than a weakness. The lack of attention given to other assorted drivers is not a strength of those drivers but rather reflects their obscurity and lack of hardening / auditing.
It's also not the norm in the Linux world to assign a CVE for a security vulnerability when it's fixed. The norm is to fix them silently without trying to obtain a CVE. It's completely bogus to judge security based on counting CVEs for many reasons. Not having public lists of the fixed vulnerabilities with CVEs assigned doesn't mean there aren't a bunch of vulnerabilities being fixed, and it's even worse if the vulnerabilities aren't being found and fixed.
Every x86 and ARM device is proprietary and has a massive amount of complex proprietary hardware, firmware and microcode. There is no escaping that for these architectures. The Librem 5 is not an open hardware device and has a proprietary SoC, proprietary Wi-Fi, etc. all with their own proprietary firmware and in some cases entire operating systems (Wi-Fi / Bluetooth, cellular, etc.). The distinction of an OS like PureOS is that they don't ship updates to this firmware but rather leave it vulnerable to all the fixed security issues, because they won't redistribute the proprietary firmware updates. The firmware is still present, but the OS is 'free'. Either way, that firmware is running, and with a bunch of known vulnerabilities if you don't update it.
Proprietary hardware and software is also not inherently less private or secure than open source software. These are differences in development model, not privacy or security. You're very mistaken if you think open source software eliminates backdoors / vulnerabilities or even reduces them. It's not how things work out in reality. Open source reduces the barrier to entry for security research, whether it's for good or evil, but it's certainly still possible without it being open source. Either way, the comparison you're making is between proprietary hardware + proprietary firmware + open source OS to proprietary hardware + proprietary firmware (but without updates shipped by the OS) + open source OS.
> Librem's security model is that of a Linux box, signed update packages
Again, you're mixing hardware and software. The Librem hardware isn't only for PureOS and will be able to run Android.
Signed update packages alone are inferior to not only having signed update packages but also verified boot and attestation. GPG also has far too much complexity and attack surface for this, and having online build / signing servers, etc. is a joke.
Android is Linux, and the Linux kernel is not a strength but rather the most prominent weakness in Android. A massive monolithic kernel written entirely in a memory unsafe language and entirely responsible for enforcing the low-level privacy/security model is not a strength. That's a major problem which needs to be resolved, not a hole to dig deeper. It's fundamentally not fixable and while a bunch of work on mitigations can help, it's very limited in what can be achieved. Moving to the desktop Linux software stacks also gives up the vast majority of these mitigations and the security model that has been rapidly improved over the years. It gives up having such strict SELinux policies developed as an integral part of the base system, as just one of many things that are lost. This level of security cannot be obtained on a traditional Linux distribution without a well-defined base system that's developed together with lots of holistic systems level privacy and security work. Addressing it in a bunch of separate fragmented projects doesn't work out, and prevents having the same kind of security model and security policies. The way that SELinux is used on Android compared to a distribution like RHEL / Fedora is day and night. It's drastically different and not even comparable at all. The same goes for the deployment of other privacy and security features / models.
Kind of, Google can release Android running on top of any OS that implements the NDK stable APIs, plus their POSIX subset, and besides OEMs no one would notice the change.
Yes, that's true. I mean the Android Open Source Project, rather than Android as an OS family. For Android as a platform defined by the Compatibility Definition Document / Compatibility Test Suite, it doesn't have a specific kernel, and Windows could have become certified as Android if they had actually gone ahead with pursuing that.
> isn't going to be particularly security-focused: no attestation, no trusted boot
This is only true initially, presumably due to time and funding constraints. From the FAQ (https://puri.sm/faq/):
> What are your plans for tamper-proofing the Librem 5?
> We hope to have a version of PureBoot available for the Librem 5 for users who want to verify it with a Librem Key. We cannot commit to it being available at launch but it’s a goal.
I imagine it would be possible to get Genode running on the Librem 5, which would be even more secure than Android. Only you'd be limited in what applications you can run.
Still, even on Linux, you can set up SELinux or Apparmor to harden your system as much as possible, run untrusted applications as a different user, compile your own hardened kernel, and so on. It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want.
> It's going to be a less secure system for casual users, but it'll allow power-users to more easily (you can do that on Android as well, but it's more difficult) secure their system as much as they want.
No, it really won't. Doing substantial privacy and security hardening requires a years of work by a team focused on it and the OS needs to be developed with it in mind. Sure, you can enable SELinux elsewhere, but you won't have anything remotely comparable to the complete, full system SELinux policies developed as part of the Android Open Source Project and deeply integrated into it. You're talking about users doing all this from scratch somehow when there is hardly any interest in it for that ecosystem. There's barely any application sandbox or permission model to speak of and projects like Flatpak are not approaching it in a meaningful way that avoids trusting apps.
You're suggesting throwing out having an application security model and all this privacy / security work to reinvent it all from scratch for a new ecosystem without existing applications. It's hard to understand how that makes anything easier.
Having the well-defined base OS with verified boot and clear separation between the OS and applications which are sandboxed and offered capabilities via a permission model is crucial. It's not an advantage for security to completely do away with that. It's important to implement each feature / capability in a way that fits into the overall security model. Developers love taking shortcuts and doing this in a lazy / negligent way, and you can see exactly that with how people implement features via the shortest path of depending on app-accessible root instead of doing it properly, even when that's a niche thing.
Attestation of what? Software security is inferior in Android (hello leaky API), hardware is untrusted in Librem sinde Day 0. Show me a TPM chip with open firmware or it's a security disaster on my board. Seccomp is a thing. Also, Flatpak is the last thing I would concider to use.
Indeed. I'm tired of each new attempt to fix Android and make it usable and safe. Apps written for Android are written to work with Google's expectations and assume the presence of Google's servers and proprietary APIs, and that's getting worse, not better.
Librem is going the right way, and there are a handful of other companies working along the same path. Necunos is another I heard of as well: https://necunos.com/community/
Yeah, and pmOS adds an interesting angle that they're adding legacy Android hardware to these companies' work on their own hardware, all running real Linux.
Note that Necunos' phone could actually be bought with pmOS preloaded as well, so you can really start to see how a few of these different projects are starting to work together and build on each other.
Hopefully we can have a truly FOSS mobile ecosystem in the next couple of years.
What's wrong with AOSP? It's fully open source, supported by a huge amount of phones and has a snappy UI.
The only other open source UI that has managed that so far is Sailfish OS.
Just dump all the proprietary Google add-ons and enjoy the F-Droid app store. You will have amazing battery life, less detractions, less ads and a lot more security and privacy.
I enjoyed this with CopperheadOS (the GrapheneOS predecessor) on a Nexus 5X until the project folded. Google stopped supporting the Nexus 5X with updates a few months later.
> Currently my Samsung Android device is at Dec 2018 patchlevel and nothing I can do about it.
Have you checked whether there's a LineageOS build for your device? https://wiki.lineageos.org/devices/#samsung (Darker links indicate a build is maintained and available.)
I hope Librem remains viable. As someone who needs some specific apps for work, I won't be able to switch for practical considerations unless those services work well enough on the device. For example, Slack.
I could carry a second device for personal use, but am unlikely to.
Exactly. How much I like the idea of a truly open phone platform there are some obstacles:
- Decent hardware available at competitive price
-- While I could make do with some degraded performance for a truly open phone concept, most people would not, especially if price point is similar to, or higher, than established closed platform brands
- Must have apps available - needed for wide acceptance
-- My personal examples of must have apps:
-- BankID (Swedish e-id, needed for banks, taxes, government sites, payments)
-- Swish - Swedish app for personal micro transactions
-- Public transportation apps (tickets/timetable)
-- Bank application
-- Signal
Without these apps, a open platform phone would be next to useless to me. And I am a big proponent of open platforms.
And looking at how reluctant BankID were to even support older version android phones, I am not optimistic to them adding a completely new platform to support.
I know people who were forced to upgrade from "old" phones because BankID no longer supported their Android version, and phones would not get newer Android version.
I've worked for over 30 years only remote on one thing or another... most of this guy's points are on the money.
Unless it's enforced to share information properly, if some people are in an office and others are not, there are two classes of political animal created immediately and that will affect everything.
Unless I missed it, he didn't get into how variable work really is... this 10h thing is kind of a crock for the kind of work I do anyway... sometimes you are blocked on the one thing you have to be doing and it's difficult to focus on things that are of secondary importance just because you should be working. Other times you're being paid, but there's nothing to do for one reason or another. You can usually find useful things to do but at these times, they already know the situation. They want you to just note it, keep your head down and do something you can do yourself that should be somewhat helpful, and pick up immediately the thing is unblocked.
It's just not always possible to move things forward for 10h each day... be transparent about it. Sometimes if it's an architectural or philosphical issue, you need to study it and then do something else while your brain thinks about it. Some days nothing is going to move forward no matter what you do because of your personal state... you learn to recognize it and let it go... tomorrow or the day after you'll be back in triple force and more than make it up. The people who are paying you usually care about results not hour by hour but week by week. So long as it's all happening on that scale everyone's happy.
I specifically included meetings, etc, in the time counted.
If you took anecdotes from office workers IRL you'd think everyone was in the top quintile. You can argue that its an unrepresentative sample (people browsing HN) but I'd postulate that people not on HN are using downtime elsewhere.
And I'm not convinced the 8+ people are being more productive with their time (as per my busy work note in the other comment). Anecdotally, the people who most complain about being busy seem to be the least impactful.
OK, so that's a strong claim, that outliers can't work 1.5 times as much as normal. I've worked in GameDev and now science... I've seen them, they exist! Some people work not just harder but longer as well, they are extremely productive compared to average.
You observe that most great scientists have tremendous drive. I worked for ten years with John Tukey at Bell Labs. He had tremendous drive. One day about three or four years after I joined, I discovered that John Tukey was slightly younger than I was. John was a genius and I clearly was not. Well I went storming into Bode's office and said, ``How can anybody my age know as much as John Tukey does?'' He leaned back in his chair, put his hands behind his head, grinned slightly, and said, ``You would be surprised Hamming, how much you would know if you worked as hard as he did that many years.'' I simply slunk out of the office!
What Bode was saying was this: ``Knowledge and productivity are like compound interest.'' Given two people of approximately the same ability and one person who works ten percent more than the other, the latter will more than twice outproduce the former. The more you know, the more you learn; the more you learn, the more you can do; the more you can do, the more the opportunity - it is very much like compound interest. I don't want to give you a rate, but it is a very high rate. Given two people with exactly the same ability, the one person who manages day in and day out to get in one more hour of thinking will be tremendously more productive over a lifetime. I took Bode's remark to heart; I spent a good deal more of my time for some years trying to work a bit harder and I found, in fact, I could get more work done. I don't like to say it in front of my wife, but I did sort of neglect her sometimes; I needed to study. You have to neglect things if you intend to get what you want done. There's no question about this.
On this matter of drive Edison says, ``Genius is 99% perspiration and 1% inspiration.'' He may have been exaggerating, but the idea is that solid work, steadily applied, gets you surprisingly far. The steady application of effort with a little bit more work, intelligently applied is what does it.
that's a strong claim, that outliers can't work 1.5 times as much as normal
Imagine you truly were an outlier. One of those 10x guys. If you were that good, why would you choose to work more hours? So you could get 15 times as much done in that one day instead of just 10?
Put the way you did, the natural conclusion to draw would be that outliers would be the guys getting their thing done in fewer hours, while the average guys trying to fake it would need to stay late.
Because you have a high drive and are intrinsically motivated. Because you find your job satisfying, want to get rich, famous or make a life saving discovery etc.
In my opinion burnout comes from working long hours in a job you don't really care about. There are plenty of people who don't burn out from working hard, they just have really unbalanced lives.
My observation is that teams that work long hours are typically disorganized and there are many sudden changes and interruptions.
Neuro-atypicality that means you prefer to stick with one thing for many hours usually have you preferring routine and well organized predictable structure.
I've only ever felt burnout when I didn't enjoy the job.
I once worked at a job I didn't really enjoy, and I worked 8 hours during the day and often 4 hours coding on my side projects. What's the difference between that and coding 12 hours doing something you love?
I have some experience in it: I was working day-and-night on my own projects at the beginning of my career - gave me a lot of money and experience, but now I know for sure that I could do it with just 20% of efforts - all my best things were written/built after some long rest periods (more than week of rest). All that experience I could learn just in a few weeks but I was too stupid to spend some of my time to read what other people do - I was reinventing all the wheels.
After that I was working in a company, 14-16 hours per day, 6 days per week. After 2 years of such work, at the end of the day I had to spend 5-15 seconds to remember names of my wife and son, my address.
So I decided to never work more than 8 hours per day, preferably less. And you know what? My earnings increased, my relationships with employers are much better now, my health is MUCH better. So I can say for sure - overworking is a waste of lifetime and gives nothing.
Good for you. Hamming worked long hours, neglected his wife and now there's a function named after him in every scientific library running billions of times a day.
Nobody should be forced to work long hours but if they want to, and it works for them - go for it I say.
I spent a good deal more of my time for some years trying to work a bit harder and I found, in fact, I could get more work done. I don't like to say it in front of my wife, but I did sort of neglect her sometimes
The fundamental problem with scrum is that bugs happen and nothing interesting from a development point of view can be predicted effort wise before hand, at least not accurately.
The right way, is to do all velocity analysis backward-looking. Create a culture where code reviews are done constantly and long after they've been merged in.
Use metrics like KLOC, duplicate lines of code, changes to code, stories completed, etc. That's the way to measure velocity. Measuring done done done by end of sprint, is really wasteful as some engineers get it into their head to pad their estimates to make sure it's completed by some arbitrary date. This just leads to a culture of padding estimates rather than completing work when it's done.
That said, I do like letting engineers pull tasks as they like. If a more senior engineer in a certain area can complete a task better and more thoughtfully, than he should have a chance to pull it.
This also does require technical PMs which can discuss and understand the cost of their stories. This is important regardless however.
I'm about to add our first remote hire to our team, where 4 will be based out of office and one will be remote. Would love to hear your thoughts on this and get some feedback as to how I should best plan for this on our side, if you're willing to share? My contact info is in my profile.
I've been the only remote worker on a team in the past, and it was a horrible experience. Ways you might be able to avoid that:
- Treat communications as a first-class management consideration for yourself and every team member. Make sure your team gets the message.
- Treat telecommunications issues, especially the quality of teleconference calls, as a top-level issue. Otherwise the remote worker will, again, be at an information disadvantage. He/she will have to choose between (a) repeatedly asking everyone in the meeting to repeat themselves, move closer to the mic, adjust the camera orientation, etc., or (b) miss some potentially important communication.
- Remember that every fun perk for physically present staff (going out to lunch together, having an after-hours beer, etc.) runs the risk of making the remote worker feel left out and not an integral member of the team. Treat this as a management problem.
If these problems are manifest, not only will you suffer the direct implications of missed communications, but you're likely to face a disengaged worker, which is fun for nobody.
You just need to embrace async communication even with one remote worker. In short: all relevant problems/design/communication solved on project channel and not offline or private coversations.
I'm about to add our first remote hire to our team, where 4 will be based out of office and one will be remote. Would love to hear your thoughts on this and get some feedback as to how I should best plan for this on our side, if you're willing to share? My contact info is in my profile.
Followed by the US. China does not need to "pressure its trading partners".
Taiwan has its own currency, does not pay tax to the mainland, has a real democracy, and is an ally to the US.
Chinese passports can devote a page to whereever they want, it means nothing.
Interesting fact... phone numbers in the Taiwanese capital begin 02. That's because when the KMT invaded, they reserved 01 for Nanjing, their base of operations when they were the mainland government, and for whatever reason they wanted to believe they would be able to retake it.
>> The PRC exerts indirect control over Taiwan's economy by pressuring its trading partners, so the distinction is academic.
That's not what happens. What does happen is China pressures international bodies like the UN and the Olympic committee to pretend if they want to talk to Taiwan, they must talk to only China.
But it has mainly cosmetic effect... eg, despite all that effort, Taiwanese passports (not issued by China) are recognized almost everywhere except China
Of course the nuclear-armed mainland is bigger and scarier than a small island of 20-something million with only conventional forces. But China has not been suppressing Taiwan's trade as you wrongly said, it has been encouraging and benefitting from it to the point it's the #1 partner with double the value of the US.
China has more power, obviously, but most of their claims are purely cosmetic, since if they wanted to truly absorb Taiwan they can put a whole lot more pressure on Taiwan than
1) letting them open factories and conduct business in China
2) letting them visit and vacation in China
3) trade with China at all
If you want an example of an actual embargo check out Iran, Cuba, for great examples of pointless aggression (from the US).
I use HTTPS Everywhere plugin for firefox... it's pretty surprising in 2019 how many network-related blogs and articles are on http links and the https equivalent is broken.
You can use Let's Encrypt, it's free. It makes me not want to listen to what's supposed to be their wisdom on networking matters if they can't even get that right.
HTTPS (and DNSSEC!) are antithetical to the idea of proper network engineering. Hierarchical, centralized control systems. Let's Encrypt being free should only make you more suspicious about who's making money from whom. No thank you.
> Every good programmer loves to learn a new language.
Er... no. I am still seeing new ways to leverage C after 40 years on it. Creating a new language is the ultimate self-indulgence.