Alexa von Tobel has high hopes for 'fintech 3.0' (techcrunch.com)
2 points by rntn 1h ago 0 comments
ESA's Nuclear Rocket: Faster Mars Missions (universetoday.com)
2 points by rbanffy 1h ago 0 comments
An origin trial for a new HTML <permission> element (2024)
72 tentacleuno 65 6/15/2025, 10:54:20 AM developer.chrome.com ↗
I don’t understand this proposal enough to have an opinion yet, but that sure is an interesting way to say both Firefox and WebKit oppose it.
https://github.com/mozilla/standards-positions/issues/908#is...
https://github.com/WebKit/standards-positions/issues/270#iss...
> Security Complexity: Proposed security measures (styling constraints, timing, and position mitigation) add substantial complexity, indicating possible fundamental issues with the approach.
"Security complexity" is never something you want to see, because it will become yet another game of whack-a-mole between browser makers and hostile websites (i.e. between Chrome and Google Ads). Does anyone believe that a standard will hold up against the AdTech industry armed with the full power of HTML+CSS+JavaScript? These are the people who brought you the "Enable push notifications? Yes/Pester-me-later" pre-prompt.
Manifest 3 for example breaks adblockers for the sake of 'security', and adverts are Google's business. Passkeys are pushed for security as well (and do have benefits) but for the average person locks you into a eco-system; another business model plus for Google.
So with that in mind, how does this benefit Google at the expense of the user? Making the permissions less explicit, or less separate from the content of a site might be a net benefit to Google... I don't know.
I might also be reading way too much into motivations, and/or paranoid.
edit: also one can never be too paranoid around Google.
I learned a while back that Google Maps was moved from maps.google.com to google.com/maps so that when people gave location permission to Maps, Google Search could also use that permission.
This does not appear to be the case, at least on iOS Safari. I went to Google Maps, gave it permission, then went to Google Search and searched for “delivery near me.” It again asked me for permission.
But it’s not that locked in. You can generate new passkeys for a different password manager, so migration is more of an annoyance, if you do it gradually. Having more than one password manager for a while isn’t so bad.
No, they do not. For the vast majority they will simply require using the two major closed OSes which desire to lock the user in. Importantly the OS layer is where they will first encounter keypass, and so that is where the vast majority of keypass will happen, which is as gp said, the lock in factor.
Advanced users such as that that browse this site, will make use a password manager. Due to the extra effort involved, such users are a minority.
It's true that a lot of people who don't really think about which password manager they should use will end up using one of those by default. (Much like happens with web browsers.)
Getting the masses to use password managers regularly will greatly improve security. It would be better if more people made a deliberate choice, though.
I believe the issue Google is attempting to solve is frustration when a single web page spams multiple permissions requests. (Location, camera, microphone, advertiser tracking, notifications, privacy policy agreements, terms of service, etc…). The benefit to Google is better fingerprinting when a single sheet allows all at once.
Edit: perhaps they will sneak in a Google automatic login as a permission to smooth user interactions.
https://support.apple.com/guide/deployment/passkey-attestati...
Modal permission prompts are very annoying but inline prompts will need to have styling severely limited (as they do here) to avoid nefarious use. Almost all web sites with a designer attached will end up continuing to use styled buttons that call the modal prompt when clicked. I guess this sort of works as a <noscript> equivalent for permissions… but you can’t use the majority of those permissions without JavaScript anyway.
This special class of element also feels like a maintainability nightmare for browser teams. What happens when I put a <div> on top of this prompt with pointer-events:none on it? Would be textbook example of how you could mask the prompt. I’m sure you can fix that but there must be a hundred whack a mole problems I haven’t even thought of.
Also those dialog designs are pretty awful from a usability point of view. In terms of design they all look identical, but the buttons change meaning pretty drastically, so you have to actually read the text. It would be better if it had some kind of slider or something that showed you the three possible states and let you switch between them consistently.
That's exactly how google would describe it with some missing context added.
Whether it's an official standard by some criteria doesn't matter.
Edit: Not sure why I'm being voted down? Can someone who disagrees with my statement explain why you'd click a button with the goal of opening a modal to deny a permission when the permission is already blocked?
Basically, I expect users wil stil need a way to defend against permission spam.
If you're on a site that follows your cursor around with this button forcing you to click on it, the SITE is spam, not the permission request.
If the goal is to let users easily identity this element as "browser-provided", then having the element "stick out" and be distinct from the page style would sort of be the point - so I don't see why styling fonts or colors should be possible at all.
If this is not the goal, then why restrict styling at all?
In any case, I don't see how users could be educated to rules like "If the letter spacing is between 0 and 0.5 em, it's genuine, otherwise it's fake" or "the font can be normal or italic, but not bold or underlined" to distinguish genuine from fake permission elements.
I get that permitting full styling would allow all kinds of dirty tricks with overlays, strategic invisibility etc, that have to be defended against. But do they really want to play continuous whack-a-mole with all the ways styling could be exploited?
The permission modal that's shown intentionally overlaps the line of death, which is exactly the same as it is today
I think the point behind this is to stop websites from spamming permission popups by moving the permission prompt to page content and making the contents browser-controlled not website-controlled. I think that’s a better model, but it doesn’t really solve the annoyance of having the “fake” permission prompt followed by the real one, does it? Won’t websites just alter their “enable notifications” fake popup to include this?
I also don’t see how this solves the “no easy undo” problem. Won’t websites just remove that element once they gain permission? Or worse, they could spoof it and fake the undo.
You're describing the "no easy undo for allow" problem. Google doesn't care about that and doesn't want to fix it, since they want more of your data, not less. This element is just to have a solution to the "no easy undo for block" problem.
it's subtle, but long term it puts more pressure on users to parse trust context visually, not functionally. if every site can skin permission requests differently, consistency breaks down. user instinct gets trained on style, not source
Original fb marketplace in india.
These fuckers ask for location on each search query, basically on each page load.
It is annoying to operate on Firefox focus and regular Firefox on android as it has a bug I assume that does not honor per site permission disable request.
Same on Firefox desktop, it works, sometimes it does not and then the site is unusable unless you deny location on each page load. Urrrghhh
We need global default off and per site permission.
Also, would it not be easier to pass dummy coordinates like 0.00,0.00 to bypass the nag screen ?
Same for notifications. "Yeah yeah notifications are enabled. Stop bothering me" ??
An <intrusive type="..."/> element. It wouldn't be styled by the site except to determine whether it was visible at all and how it was positioned on the page. The element would support a dom api to query information corresponding to it's type (eg location, video, etc). The element would only provide information when it was fully visible on the page. It would display on top of every other element on the page, and wouldn't be permitted to be positioned on top of other <intrusive> elements. It would display to the user a visualization of the information being provided to the website. For example, an <intrusive type=location> element would display a map with the location the browser is giving the website being positioned on the map.
By default, if the user didn't interact with it at all, it would give the page "fake" information that doesn't require permissions to know. For example, for location, it would display the location on a map as determined by the users externally visible ip address using geoip. For video, it would display a static avatar. For audio, it would perform text to speech based on whatever is typed by the user. The element would contain a short text explaining that this is what it is doing (eg: "Location: coarse"; "Video: avatar"; etc). The user could click/tap on the element to configure what information it provides. For an <intrusive type=location>, a dialogue would be displayed suggesting the user either give "fine", or "coarse" location to the site. A preview of what the intrusive element would look like afterwards would be given for each option. The default selected option would be whatever the currently selected option is, eg "coarse" for location. There would be a button marked "continue" which would leave the current option selected. Since users often click "continue" (or "ok", or even "cancel") without thinking about what they are doing, this would cause the permission to "fail safe".
In case you got a stupid-ass machine-translated version.
Maybe they want to bring a whole lot of other elements in to allow that type of access, but I wouldn't put the carriage before the horses.
Looks like they try to "fix" an issue that should be fixed on the browser's UI side.
That's a joke, who cares....