that's beautiful!
3,322 karma · joined February 16, 2010
email username at gmail
kismet: dfc172b9747a2945c00ed47fae2f07f7b73cb476b65f0c60580a8549bd7040f9
Or, with the subject matter being tech, most potential readers are fluent anyway?
Very cool to see a team use Jepsen for super early pre-release testing of the system.
I wonder if you wish you had waited for the runtime to be a bit more stable, or you feel this was already well worth the effort, even with some of the identified failures being in "known incomplete" areas? (I could see either side of the argument - waiting longer might give you more valuable failures, but testing early gives you a chance to catch problems before they become baked into the foundation and become more difficult to fix...)
Another tool that feels like sci-fi to me any time I hear a mention of it, is Antithesis [1] - written by the people who built FoundationDB. Could be another interesting integration to investigate in the future to help bulletproof the language runtime?
I wonder how this will pan out... very interesting to see new approaches being explored.
That's... uh... a pretty bold description for a tool where you are in fact outsourcing the "imagination" part to the machine.
Thanks for sharing this, so cool to learn about it!
> I never suggested energy consumption wasn't a concern. I said any code that runs expends energy.
I don't think anyone would argue otherwise.
> So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike.
I think you're ignoring the fact that running it for PWA's requires spinning up the entire browser engine in the background to run the ServiceWorker. That's considerably heavier than the minimal amount of native code required for a native app's notification extension. It's not the same cost/benefit calculation.
> So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.
Ok, but you're handwaving any potential privacy/energy issues away out of hand, and suggesting they are simply a smoke screen, and any and all discussion that I am sure went on over the course of arguments over the W3C spec as a nefarious cover. Again... from that point of view, I don't understand why you think anybody would even bother defining and implementing _any_ of this, if that was the goal?
> I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?
Right, you can't speak to it because it's too vaguely defined - so how can a computer universally and accurately judge the same thing without a precise definition?
And, unless I am mistaken, there IS no automatic heuristic for native apps either. I personally don't think it's even possible to define one, because there's no way to universally judge from the shape and content of a message whether it's benign or not, just like you can't judge from simply seeing an SQL statement like "DELETE x FROM y WHERE z" whether it's a valid request that should be processed, or a malicious one that should be denied - it all depends on a ton of context - and you DON'T have the same context between a web notification and a native notification.
> That's quite the straw man, considering Service Workers can't even access the geolocation API.
Sure, I am exaggerating for illustration. My point is there is no way to just handwave the complexity away with "there should be a magic heuristic that can distinguish good requests from bad requests"
> But also, the geolocation API requires explicit user consent.
Push notifications also prompt for user consent. Watch me pop up a request "Accept my push notifications from spacexlottery.com for a chance to win 1000 DOGE from Elon Musk!" and see how many acceptances I get. And that's the most trivial idea that comes to mind - a real gray or black hat would come up with a dozen more plausible options in 30 seconds, and a dozen ways to exploit access.
> But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?
Because if I pull this with a native app, I'll get my app (and maybe my developer account) banned, probably sooner than later (and even so there's still a ton of scam/clone apps on app stores, because the reward is much greater than cost, and real black hats don't care about getting their accounts banned all that much).
If I pull this with a web app, there's nothing to ban... maybe a domain name, but those are infinitely available.
> So associate push notifications with a specific account in some way, similarly to how native apps work.
Sure, and...
1. What account do web developers use for sending notifications to Chrome, Mozilla, Opera, Konqueror, Ladybird users if they want to implement the notifications spec?
2. Is this a free developer account? Then there's no more friction than having no account.
3. Is this a paid developer account? I can just imagine the uproar :)
> My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible.
Fair enough opinion to hold, for sure. But, you know, companies are made of people, and people who work on things like browsers or new specs like this tend to be idealistic, I would suspect.
It's easy to see the world as a place full of evil bastards (and often enough it is). Even so, I'd say tech / open source / open standards is something that is a great achievement of humanity, which wouldn't exist without people wanting to help each other and fight for a better future. And often times, the people building these things do need to also consider the fact that yes, the internet _is_ also full of evil bastards who will gladly abuse the things they build against every single user.
Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:
> Activating a service worker to deliver a push message can result in increased resource usage, particularly of the battery. Different browsers have different schemes for handling this, there is currently no standard mechanism. Firefox allows a limited number (quota) of push messages to be sent to an application, although Push messages that generate notifications are exempt from this limit. The limit is refreshed each time the site is visited. In Chrome there are no limits.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Push_API
Anyway, let's put a defensive hat on for a moment, and assume we're dealing with malicious actors (and OF COURSE we're going to be dealing with malicious actors, this is the internet, come on).
> Surely this wasn't the only option to "protect user privacy and battery life".
First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.
> Native apps can handle push subscriptions without this sort of flag.
Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work with.
If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).
>> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.
> This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.
I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.
In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?
But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)
I found it gives me just enough friction that most of the time, the impulse to open the app passes while I wait for the breath timer to run out. Simply using the OS screen time limit on its own is not really enough, because it's too easy to dismiss and override the block. Having a brief timer to help you consider whether my action is intentional or driven by anxiety or thoughtless boredom really helps.
Once you open one of the reference handles and modify the contents, the copy-on-write process is invoked by the filesystem, and the underlying data is copied into a new, separate file with your new changes, breaking the link.
Comparing with a hardlink, there is no copy-on-write, so any changes made to the contents when editing the file opened from one reference would also show up if you open the other hardlinks to the same file contents.
Even if you consider the hardware "tech jewelry", isn't it strictly better to have a way to run Linux on it instead of sending it to landfill? Seems silly to exclude a particular set of hardware from consideration for arbitrary reasons?
Option 1 - my home robot makes a sudden movement, catching me off guard, and smacking me across the shins (or worse).
Option 2 - my robot loudly announces "warning, moving to the left in 5, 4, 3, 2, 1", which drives me insane after a few days.
Option 3 - my robot taps into a million years of non-verbal communication that humans have evolved, and indicates what it is about to do both with more subtle audible and physical cues.
PS: regarding "display attention" - trivial example, "hey assistant, remind me to do X on Sunday"
- option 1: no attention display, I have no idea whether my request has been recorded
- option 2: verbal or auditory or physical cue that assistant is listening, and a cue to confirm that the request was processed successfully.
https://machinelearning.apple.com/research/homomorphic-encry...