HN user

Sayrus

1,619 karma

Personal blog: sayr.us

Posts10
Comments334
View on HN

Not familiar enough about GCP internal, but AWS prices are way higher than what's quoted in the article. You'll get billed for bandwidth, should you want any logs of your control plane you'll pay them at a premium so high* it will dwarf the cluster price and machine price combined. And for ~$70/month, you get the cluster API, not the EC2 compute required for worker nodes.

* Because vended logs to s3 are not supported (https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS..., https://github.com/aws/containers-roadmap/issues/1141)

It really depends on the market you are targeting and your threat model. If your threat model allows future decryption of the data by a passive listener, then you don't need to rush for PQC. If you are worried about your communications being archived for future decryption, then you need to deploy PQC now even if QCs aren't developed for decades (or ever).

The assumption that you care about this is baked into ANSSI certifications, otherwise you would usually not bother certifying your product. They warned in 2022 that they would do this (See Phase 2: https://messervices.cyber.gouv.fr/guides/en-anssi-views-post...) and will allow PQC-only algorithm no earlier than 2030.

I misunderstood your initial point about logging-in. On PayPal logging in requires my phone, even with hardware 2FA because sometimes it decides my new IP/Browser/luck isn't trusted enough so it needs to send me a SMS/WhatsApp message so it didn't even register with me that you would be talking about taking out your phone as an additional friction. I see that now, in which case: you're completely right. WeRo requires a phone and one that uses either Google Play Store or Apple App Store and worse, depending on your bank that requires strong Play Integrity.

In term of implementation, WeRo looks more like a response to mobile payments like WhatApp, WeChat, Alipay, ... than a response a provider like PayPal. However, I haven't seen anything that'd limit them from expending support if they wished to.

and also giving numbers out as much as possible

In Person-to-Person, you don't have to share your number. You can use QRCode (Direct SEPA). I'm not entirely sure of the email implementation, but maybe these do not share the phone number either (Edit: seeing https://support.wero-wallet.eu/hc/en-us/articles/25599201237..., it seems you may be able to do an email-only account). In Person-to-Merchant, I'm not sure what information are shared.

Moreover payment systems that prioritize the needs of merchants usually are horrible for consumers

Supporting merchants flow to pay is different from prioritizing their needs so I'm unsure where you're going from there. It's also completely separated from Person-to-Person payments. PayPal supports Person-To-Merchant and I wouldn't say they are great for merchant.

Remote Attestation 10 days ago

Which makes you update hardware and have a window where you are vulnerable. It's terrible but not a blocker and as long as Intel releases new architectures it isn't much different from software issues. As far as I know, Granite Rapids SGX fused keys (FK0, FK1, GWK, FEK) were not yet extracted. Granite Rapids was released around ~2024 meaning an attacker need to hack the provider and perform a new extraction on SGX.

Remote Attestation 14 days ago

Since there have been multiple 0-day in kernels, we should drop all security boundaries in them because you'd only need execution on the machine and a known vulnerability.

Since there have been with bypass on service X, we should remove auth because all you need is the vulnerability.

Address space layout randomization wouldn't exist with this mindset, and yet it does and helps for many exploits.

SGX is not fully secure. But neither are the other part of the stack. Security (or trust in this case) is done through layers because it's a question of when you'll be vulnerable, not ifs.

As much as I love to discuss how expensive AWS is, I find this comparison quite strange:

- Small instances are used, including a burstable instance for AWS, with no indication on where and how much throttling happened. Saying that the instance is burstable but a price-match isn't even true because later it is discussed that $48 is not a match in price due to services around the instance itself

- It seem Hostim doesn't support large instances, the largest dedicated instance offers 100GB / 4 Cores / 8 GB RAM. At that price point, you either go with AWS for prototyping speed or compliance but definitely not for performance.

- Talking about speed, you got performance, but you'll now spend time developing your own backup and restore processes which are a "coming later" feature. What's the impact of backups compared to disk snapshots on those other network-attached disks?

- It mentions only once the network-attached block storage used by RDS and the Hetzner instance compared. Which is weird because you could go for local storage for cheaper and get more performances, but that introduces some trade-offs.

- Instances are configured with different settings.

Peeker's advantage is not directly related to fog of war. The peeker is moving so before the movement is even sent to the server, the client's camera began moving. As such, the peeker will have at least a tick, usually more before that new position is available to the opponent.

"Fixing" this would make movement sluggish: any movement would need to be validated by the server. Meaning delay between pressing keys and actual movement.

Why stop at tracking license plates? Once you've started you should report on pedestrians, bikes, whether people are at-home, which building people are entering, the way they walk and many more. Those are all "alternative revenue streams" that are as valid from the operator/investor point of view and completely unrelated to whether the way of transportation or activity is meant to be untrackable or unrelated to a way of transportation at all.

There is also a factor of scale: a cop can follow you, but a system where everyone is monitored 24/7 is a very different story.

Tokens saved are tokens saved.

Not always. RTK strips flags and other information. Sometimes you spend more tokens getting them back later. Sure your saved 70% tokens on that tool call, but nothing in the metrics says whether you ran 3 tool calls instead of 1.

There is also a question of whether that stripped output requires more thinking tokens or not.

I'm not sure how Garmin works, but for instance with Google Wallet-compatible watches, you need a phone where wallet can run. I've had this setup for a year where I loaded the cards from another phone and used a watch to pay.

However Wallet didn't like this setup. Tokens expired at varying delays, sometimes a day, sometimes a week or payment failed without reasons.

Nowadays, I just use my bank's app which work fine on GOS.

Most panels are from China. Panels have a very long lifetime. Over their lifetime they generate way more than their price in oil. Europe is not a huge producer of oil and relies on imports to sustain its usage. Sourcing panels is effectively reducing the amount of money leaving Europe in the long term.

Now that the attack window has changed to 7 days, all new exploits like these will come with time bombs to not trigger until 8 days.

Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.

You still need criteria to handle reputation: does an account invited years ago and now spamming affects the reputation of the inviter, how much? What about the hacked accounts?

For small platforms it makes a lot of sense, for larger the potential for abuse is still there in different forms.

Gecko doesn't have a WebView implementation (GeckoView is not a WebView implementation), so it has to be used alongside the Chromium-based WebView rather than instead of Chromium, which means having the remote attack surface of two separate browser engines instead of only one. Firefox/Gecko also bypass or cripple a fair bit of the upstream and GrapheneOS hardening work for apps. Worst of all, Firefox does not have internal sandboxing on Android.

The sandbox has been gradually improving on the desktop but it isn't happening for their Android browser yet.

Context is definitely interesting to have with your statement (From https://grapheneos.org/usage).

Thanks for writing all this, this really shows how the failures you encountered don't overlap with my use of the phone.

I don't use RCS and Android Auto.

I have HeliBoard to replace Stock/Google Keyboard. It is way ahead the stock keyboard experience but far behind Google Keyboard's, especially when writing in two languages.

Tap-to-pay works with my bank apps. But that means I can only use one card unlike with GPay.

I rarely use second account as the latency to switch from one account to the other is a pain. I only have a secondary sending notifications to the first one.

I don't let the phone auto-reboot for installs, I let it install automatically and click reboot when I want it to install.

I am on a physical SIM / different carrier and never encountered network issues so I can't comment on that one.

I think parent is talking about Play Integrity being integrated into banking apps. It's a hit or miss depending on the bank, some will be fine without, some with integrate it but not rely on it to directly refuse login, some will require a lower integrity level, and some will actually require the highest integrity level leading to issues on custom ROMs.

I've been using it for a bit over a year. Installed in a few minutes thanks to WebUSB. A bit of research needed to set the right permissions on Google Play Services.

After that? I only had one application fail due to Graphene's memory allocator. No weird bugs, no need to restart like some siblings are commenting. As close to the "Graphene just works" as it could be.

However, I'm not heavy into Google's ecosystem. Google Pay will not work but I'm not a user, some Google features won't tell you why they don't work but I'm not using them either (Quick Share for instance), none of my apps require the highest Play Integrity level. Maybe the person who say this are a specific type of person where use-cases don't overlap with what breaks on Graphene.