Hacker Newsnew | past | comments | ask | show | jobs | submit | esprehn's commentslogin

The proposal already exists [1], but vendors would need to agree to both prioritize and ship it.

Right now Chrome is much more focused on AI related APIs (sigh) and not stuff like FontMetrics.

[1] https://drafts.css-houdini.org/font-metrics-api-1/


The FontMetrics API solves this, hopefully browsers will ship it someday.

https://drafts.css-houdini.org/font-metrics-api-1/

RIP eae@.


It can request with a JS call. It can't passively collect it without you approving first. The article is written like calling that JS function will turn on location tracking without consent.

He explicitly says he can't determine it, but that the location tracking as configured will turn on once the user grants consent. All true statements.

How would you have written it differently


"If the user chooses to opt-in and grants location-tracking permission, the app is then, and only then, able to track the user's location?"

You would be lying if you wrote that because you do not know if that is true.

But that's not true; it could easily fallback to other forms of geolocation like using the current IP.

That would allow you to see the local network IP (not actually sure you even get that, tbh). To get more detailed information about IP configuration, you need Location permission. Been there, done that. Most Android network information calls provide degraded information if you have not been granted Location permissions.

If an app can make an HTTP request, the app can know the user's public IP address and the geolocation derived from that.

This data has well-known limitations, but I think it is the fallback people are talking about here.


Good lord. So could literally any app on the planet

This is very cool, but I'm confused why the React player is smaller than the HTML player. What's actually in the size comparison there?

It’s largely because (1) the React runtime is not bundled so it’s technically not apples to apples, (2) the Web Component includes CSS as well since we’re using Shadow DOM.

Basically few kB for CSS and few kB for a thin “framework” layer for managing attr to prop mapping, simple lifecycle, context, and so on.


The worker situation would be much better with inline workers (or modules).

https://github.com/tc39/proposal-module-declarations

Unfortunately the JS standards folks have refused so far to make this situation better.

Ex. it should just be `new Worker(module { ... })`.


We haven't refused, it just takes time! There was an update at the meeting two weeks ago [1]. There's a lot of other machinery which needs to be specified and implemented before module declarations will work but it's coming along.

[1] https://docs.google.com/presentation/d/1inTcnb4hugyAvKrjFX_X...


It's all about security, see my other comment. https://news.ycombinator.com/item?id=47480080

No one really does, but there's one particular individual who keeps pushing to support things like node 0.3 and who also maintains all those low level intrinsic packages.

2022. I'm not sure phones recorded useful video in 2002.

Right. It’s a little hard to parse but they’re saying “The NYT has a typo”

And what he's implying. "The NYT has a typo, it's all garbage!"

They're implying "An establishment calling itself a 'newspaper of record' can be expected to have high standards, such as correctly reporting dates, and I'll hold them to that"

If you can spot a typo in the first few seconds of reading a piece, so can the editor and sub-editor before it's published.


Myself and most other programmers I know have at least once (more like 100 times) had the experience where you can't figure something out in some code you've been staring at for an hour, then another person comes along and immediately sees an obvious glaring error that you missed.

I can only imagine the same thing happens in newsrooms with text, especially when it is visibly very similar, like "2002" and "2022."


That's why all news stories are supposed to be reviewed before publication by a second person

Newspapers used to have copyeditors for this kind of thing. I thought NYT still did.

They do and yet they also can make errors

Youd expect them to have a checklist too though.

The process these days is more like publish then do editorial review. See it on major outlets all the time - break the story as early as possible, get the eyeballs and ad revenue, then get it cleaned up for posterity.

Sometimes this results in radical changes to a piece within hours of publication - yesterday for instance the BBC ran a piece headlined something like “I watched my father murder my mother”, and six hours later in slides an editorial correction saying “she did not, in fact, see her father murder her mother. She was asleep in another room at the time.”


Sony Ericsson P800 from 2002 had 640×480 videos captured from its camera :) While I wouldn't claim the quality is great, you could tell more or less what was going on.

The missing camera light seems pretty serious. Any sandbox escape can turn on the camera and record without you noticing. Or your school or employer could. If you're in full screen mode the menu bar is hidden too. It's a very strange move for privacy centered Apple.


The indicators are controlled along with sensor access at a very low level within a secure “exclave” from the main kernel; this is how the on-screen indicators have worked on iPhones for a few years. The indicator is rendered within the display controller at the firmware level, so can’t be affected by anything in _either_ user mode or kernel mode. [1][2]

1: https://randomaugustine.medium.com/on-apple-exclaves-d683a2c...

2: https://asahilinux.org/2021/08/progress-report-august-2021/#...


Ah this is what I missed: https://daringfireball.net/linked/2026/03/12/macbook-neo-on-...

It's not just the menu bar icon (which can definitely be spoofed), but an on screen dot where the system is controlling pixels directly bypassing any OS level drawing on the screen.

Related: https://www.reddit.com/r/iphone/comments/1in0681/iphone_16_m...


The web doesn't work without dynamic feature detection. I couldn't find anything in the component model about how this is expected to work.

The DOM is not a static interface, it changes both across browsers based on implemention status and also based on features enabled on a per page load basis.

The multi browser ecosystem also mainly works because of polyfills.

It's not clear how to polyfill random methods on a WIT interface or how to detect at runtime which methods exist.

OTOH the JS bridge layer we use today means you can load JS side polyfills and get wasm that's portable across browsers with no modifications. There's more to the ecosystem than just performance.


Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded.

Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.


Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: