Ummm, extremely large teams develop monolith (single binary) things called OSes or databases etc. The modularity for scaling developers cross-communication comes from.... modules! duh! Aka libraries.
2,041 karma · joined March 28, 2013
1. First, once you "local root" within the sandboxed process what can you compromise?
a. Can the session cookies be stolen? (Think gmail inline attachment rendering a malicious webp image).
b. Can you launch attack on other local network resources from within the compromised sandbox – read insecure filesystems, make tcp sockets to local resources etc – these are not prevented by OS sandboxing capabilities that Chrome depends on.
2. Second, can you probe for vulnerabilities in OS sandboxing that chrome depends on to break out of sandbox? On older unpatched OS versions this is definitely possible. These attack vectors may have been fixed in newer patches of OS already so you won't see a new CVE and patch for the same from the OS vendors.
H1B, L1 etc visa schemes make you indentured to the system. The longer you stay and invest in your home and social life (which as a human you have to, otherwise you become a mindless drone), the more you are indentured to the system. Indenture is built into the visa contract – you cannot quit your current employer and stay unemployed even for a short period of time – even though you did contribute social security every single month, even though you paid all taxes every single month – you get no benefits.
So, you are in constant fear of losing your job and having to throw away your entire investment here. This means you will be pliable in many ways you would otherwise not be. You can be denied promotions, you can be given shitty/grunt work, you can be given borderline unethical work, you can be asked to fire other people in unsympathetic ways, you can be asked to work weekends and nights without any overtime pay, you can be asked to travel very long distances for work in economy class and so on and you shall not complain.
You can only suffer silently until you get another job. Btw, you cannot get any random job you like. You have to get a job where the employer is willing to go through the rigmarole of visa process - which narrows the field significantly.
If you want to change societal standards, you can make meaningful impact only if you are powerful – power through money, politics or influence. You don't make any impact on society through your own lone-wolf personal sacrifices in your private life.
Ergo, work towards becoming powerful first and then work on using your power to make societal change.
Btw, world needs all kinds of people doing all kinds of work. Most work is towards keeping the world running as it is (KTLO work). Very little work that happens in the world is venture bets (trying something crazy new that might work). Then there's some work that actually results in changes to societal norms - those are strategic bets. Only the powerful get to make those strategic bets. Note: Power is most often in the form of having shit tons of personal money to spend. And sometimes in the form of political power and through influence over masses (rarely you get either of those without making friends with people with money). It is extremely rare to be powerful without either.
It is good to know lockdown mode stopped this attach chain.
Given this has happened so many times, new security posture for a normal/regular security conscious person should be:
1. Disable iMessage.
2. Enable lockdown mode.
3. Disable iCloud. (If you choose to keep iCloud enabled, definitely enable Advanced Data Protection and disable iCloud Web, disable passcodes and keychain on iCloud. Disable iCloud mail – it uses 3rdparty proofpoint for scanning – more surface area for compromise).
4. Don't store password and 2FA together in the same system like 1password. Always use FIDO2 physical key based 2FA, if available.
You cannot hide from advertisers if you use a smartphone with apps. App developers who put ads within their app control the apps behavior completely and hence they can fingerprint your device and track you very well without using IP addresses. And within browsers, they can fingerprint you through many javascript features of the browser. Hiding your source IP does very little for your privacy.
Almost all traffic (apps and websites) are encrypted via TLS (https, for example). So, even if you are on an insecure network, unless your OS's TLS certificate store is compromised, your communications are encrypted and protected against snooping from that insecure network.
Also, even on open wifi networks, today, it is very unlikely that the wifi is running without at least WPA2 encryption. Most modern airports run secure wifi. (But they also monitor all traffic metadata for illegal activities).
So, using a VPN as an exit node is just privacy theatre. VPN exit nodes in faraway countries are useful for bypassing content censorship in your own country, but it works only if the content streaming service cooperates with you.
Remember, all ISPs are heavily regulated by governments and can be asked to mirror specific customer's traffic for analysis. I would be very surprised if they don't proactively do it for all VPN operator nodes by default.
You need safety guardrails for any deployment of code or config – a clearly defined unit of deployment that is version controlled, changes going through a repeatable automated flow in which lints/tests can be added, changes can be rolled out atomically all at once, or rolled out with careful control gradually, can be rolled back to a known safe version instantly when needed etc. All of this applies to config and code (binary).
Within code, having feature flags, dynamic config variables, experiments that can be ramped up slowly and ramped down automatically upon regression detection etc – these are mechanisms to make your life easier when you have unknown-unknowns manifest to bite you. And they always do in any non-trivial real-world large-scale distributed architecture application that needs to evolve continuously.
And these unknown-unknowns are not just code bugs, they are mix shifts in usage patterns, data etc causing unanticipated behaviors too. They are old stale stored state interacting with new code that you didn't test for. They are changes in code outside of your control – like remote services or OS/language libraries – that you assume to be mostly stable and don't exhaustively test every single time – that you don't even know when they changed - that change behavior without changing interface etc. These are real-world software systems problems.
If your software is built like an appliance – frozen in time and doesn't change ever after, is stateless, doesn't interact with outside world etc – then you don't need any of those guardrails and you can keep your code simple.
1. software stack – big fat "firmware" should not exist. Entire stack should be upgradable safely, securely and frequently during its official supported lifetime and should be open-sourced for owner's own upgrades past end of life. For this, the hardware stack needs some amount of standards compliance.
2. Vendor should clearly declare/advertise the period for which they will support the device. During this period the device vulnerabilities should make them liable. After this period, they should mandatorily open-source the device drivers and unlock the boot loaders to enable free software alternatives to work on them. For certain class of devices, there should be mandatory minimum period of support.
3. Networking capabilities should be legally standardized and verified/certified before being released to market and checked for continued compliance and fined if out of compliance.
3.1 Use of latest mainstream TLS with valid certificates should be mandated for all communication.
3.2 If there is outbound communication from the device, it should make it clear to which domains it will communicate with so that it is easy to allow only that through firewall and keep everything else locked.
3.3 IoT should not accept inbound communication without authentication.
3.4 Follow best practices w.r.t rollback resistant cryptographically verified secure and brick-safe software upgrades.
Apart from classical robbery held at knifepoint or gunpoint and taken to an atm and being robbed or being blackmailed to actually do instant money transfer online which do happen, there are other lower threshold but more frequently occurring and more painful cash "thefts".
One eye-opening story I learnt a while ago was this: the women daily wage workers (or the household help that comes to my home) who are typically the breadwinners for the family are coerced by their drunk husbands to give their hard earned cash which they will waste on more alcohol or gambling. This was the situation for decades. Now, with zero-balance, zero-cost bank accounts being made available at scale in India, these women can now keep their money safe and provide care for their children by refusing to give money to their husbands (usually it involves telling them they don't have the money to give when in fact they do in their banks). Such is the social reality for so many.
You can solve for that by having short validity of the offline tokens on device and having that equal the cool-off period for reclaiming those funds when new device is provisioned. If I had ₹100 unspent tokens in my offline capable device that I lost, and got a new device provisioned the same day, then that ₹100 will show up in my account and be available to load on my device only after, say 7 days, of cooling-off period. In those 7 days, if someone who found your device could spend it and if so you lose it. If you know you are likely to be offline only sporadically for few hours and not for days, you can reduce the validity (and hence cooling-off period) significantly to just 12 or 24 hours.
Vast majority of people are working on building some feature functionality or enhancing an underlying system infra for more scale or performance or such non-functional capability which they genuinely think will improve user experience and hence make users prefer to use their product more than anything else.
People didn't focus on business metrics (most people don't know what they are) – this was most disorienting for me. It took me sometime to understand the luxury provided by strong margin business that is google ads which allows you gloss over short-term inefficiencies while exploring new product spaces.
It is assumed monetization in the form of ads or subscription can be done if there is strong user engagement for the product and that revenue vs cost equation will work out. (If not, they kill it, which they do badly). Another culture at Google is people are openly critical of their product in very large internal discussion forums.
If both parties are offline, can you still make a secure transfer of stored value? Yes, with a trusted execution environment and cryptography, you can do it. So, yeah, smart card works; a smartphone works, a feature phone with NFC smart card works etc. For each, the risk profile is different which affects the answer to the next question.
Then, when does reconciliation happen? When either party goes online? What if it is not a closed loop system? Then, reconciliation needs to happen for both parties independently. How long can either party stay offline and continue to make transactions? Is it both send and receive or only send on one side and only receive on another side? What if one party (merchant/receiver) is more likely to be online (almost always). Does it just become online payments problem then? NFC tap and pay is exactly this scenario.
In India, right now, we have NETC stored value cards for closed loop systems like metro. For open systems like UPI we have recently introduced offline payments capability with very small stored value stored as tokens on the mobile phone and used for very small transactions. As the banks learn the real-world operational risks, the wallet limits and transaction limits will be increased.