Hacker News new | past | comments | ask | show | jobs | submit | fstanis's comments login

something something security


I think the main point is the theft protection and protection from state. The US and the UK's democratic systems are broken.

In the US the social structure is slowly collapsing which increases theft and other petty crimes, at the same time the federal state has a huge surveillance power.

Solving the societal and political problems so there is less incentive having your iPhone stolen is hard. Expecting a state-like company to benevolently save you is the way they cope.

TBH without the EU, legislation like DMA would also be hard to come up with. The independent countries have less power to exert over American behemoths. This is the nice thing about EU.


IIUC, SHA-3 isn't actually better in any known way, it's just meant to be a vastly different algorithm so we'd have an alternative to the other ones.


SHA-3 doesn't use addition: from a hardware implementation standpoint this is a huge, huge advantage because there's no carry propagation delay.

SHA-3 is by far and away the most elegant modern cryptographic hash algorithm.


It's conceptually a lot different not just internally but in that it's equivalent to an automatically finalized hash and could eliminate a class of accidental misuse.


sha3 is a lot more power efficient when implemented in hardware, which is nice when you have an IoT device that needs to do a lot of hashing.

It will also be really nice on amd_64 CPUs for doing large amounts of hashing if they ever get a sha3 instruction.

That said, hashing is rarely your bottleneck so there's not much urgency.


IIRC "The Design of Everyday Things" makes a point that most devices have poorly explained errors (beeps, error codes etc) because nobody chooses what to buy based on how it acts when it's failing, so there's no incentive to spend money on it. For hardware, the cost is quite literal, as having a better display just to show error messages is a lot more expensive than a beeper.

With software, it's probably a matter of prioritization, why invest into explaining errors when you can work on preventing them? Not that this error prevention always works out, but still.


Do you believe Chrome should remove the developer tools to protect users from harming themselves? I mean, it's literally one key press away.


Yes, actually. Then every website wouldn't have to litter the console with warnings to users about pasting in code. I would much rather just have Chrome Developer Edition.


But… I "need" those tools to undo the harm that some websites try to inflict on me. I use them almost daily to delete things like taking 25% of my window for a scrolling and animated banner trying to sell me their irrelevant-to-me Excel add-in (annoyingly, this example bypasses all adblockers, comes with a widget that resizes it to a 'mere' 5% of my window, and forgets my choice every time I load or reload any of their pages). I also sometimes use them to repair malfunctioning pages so I can actually use them as intended.

Sure, you could say that I should just use this "Developer Edition", but that requires me to have access to install it on every puter I walk up to (just to be prepared for somewhat common web attrocities like full-page elements that prevent me from interacting with the page in ways that I feel should never be forbidden).

I don't tend to see 'warning' messages in the dev console that seem to be attempts to dissuade me from using the dev tools. Maybe…twice in >20 years?


If there were two separate versions of Chrome you can be sure there'd be people trying to block the dev version because they'd think using it is hacking or someone being tricked and everyone would be adding 'no-dev' scripts to their pages and we'd lose out by moving the web closer to PDFs.


This repo explains some of the bluetooth headset issues on Linux: https://github.com/pali/hsphfpd-prototype

> But because neither audio server is interested in implementing functions for embedded displays, neither power supply daemon is interested in implementing audio routing, encoding, decoding and playing functionality, neither input layer software is going to process battery and power relayed functionality and also it is not up to the modem software to register input devices into kernel and process button press events, the only reasonable solution for this problem is to provide another software which would own HSP/HFP AT modem connection for remote Bluetooth devices and would forward commands, signals and requests to appropriate application.


They can only hit a JSON endpoint in the same DNS zone (eTLD+1) as the sender's email, e.g. if the email is from sender@mail.example.com, it can only hit endpoints on example.com and its subdomains.


So, it breaks the concept of forwarding emails?


From the spec:

> The email client strips out the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message. This is why it is important that an email provide alternative content in the HTML part.


That sounds like it avoids accidentally breaking email forwarding by intentionally breaking email forwarding.


The full list of supported AMP components is here: https://amp.dev/documentation/guides-and-tutorials/learn/amp...


Ads in Gmail are not related to your emails: https://support.google.com/mail/answer/6603


At the moment they aren't, but they used to be and very well could be again in the future. Also, that link says nothing about Google not "reading it, learning from it, modifying it and hiding some of it from you", when it comes to your emails, which is GPs stated concern.

Google still saves and parses every email it gets and likely uses that data for a number of purposes. No longer directly targeting Gmail ads with it really doesn't do much for people who are concerned about Google and privacy issues.


>Google still saves and parses every email it gets and likely uses that data for a number of purposes.

Sure, but so does literally every email provider. Storing your email and spam classification are pretty much the two biggest features an email provider can provide.

This is like objections to "algorithms" or "chemicals".


> Email is still an open platform

Open in what sense? For example, there's no open standard (to the best of my knowledge) for the HTML used in emails right now and different email clients render HTML in emails differently.

On the other hand, the protocol itself is standardized, but AMP is not working on protocol level.


Emails only support a subset of AMP, so iframes and any form of JavaScript (other than the whitelisted AMP components) are not allowed.


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

Search: