[HN Gopher] An experimental Android WebView Media Integrity API ...
___________________________________________________________________
An experimental Android WebView Media Integrity API early next year
Author : brycewray
Score : 326 points
Date : 2023-11-02 19:19 UTC (3 hours ago)
(HTM) web link (android-developers.googleblog.com)
(TXT) w3m dump (android-developers.googleblog.com)
| rubenv wrote:
| Good
| riku_iki wrote:
| Probably started working on some more cryptic solution already.
| jahav wrote:
| Probably, but I will take this victory. Google has power to
| make this happen.
| riku_iki wrote:
| > Google has power to make this happen.
|
| they will have more power once current anti-trust trial will
| be over.
| happytiger wrote:
| I mean this is the problem with the entire situation. I
| immediately read the article looking for any evidence that they
| would abandon the direction of the idea rather than do what
| Google does sometimes and roll out a POC on some other less
| controversial part of their infrastructure and then come back
| to it when the timing is more right (like after a large
| cybersecurity event happens, mark these words). They did
| _exactly_ that. They rolled it back to the Android team and
| promised to perfect a smaller effort in a less controversial
| sandbox but rest assured they are publicly saying only that
| they are retiring the effort for the web _for now_.
|
| I really wish Google would go back to being the champion of the
| Open Internet I once knew them for and step away from the
| MBA'ification of everything they keep trying. Seems like the
| moment they dropped "don't be evil" they started going there.
| It's exhausting.
|
| Instead of celebrating a victory, every one of the Open
| Internet crowd gets to celebrate a smaller project execution
| and nothing but a pause in the web platform version of it. Yay.
| heywintermute wrote:
| Repo has be archived - "NOTE: This proposal is no longer
| pursued."
|
| https://github.com/RupertBenWiser/Web-Environment-Integrity
| mynameisash wrote:
| Actual blog post title is, "Android Developers Blog: Increasing
| trust for embedded media"
| brycewray wrote:
| True, but that seriously buried the lede. Sorry for the edit.
| endisneigh wrote:
| Why not post the repository instead of editorializing?
| brycewray wrote:
| If dang thinks that's better, fair enough.
| rhizome wrote:
| "WEI" isn't used on the page.
| nickthegreek wrote:
| They used Web Environment Integrity in the post, not the
| acronym. They did tag it WEI as well.
| WarOnPrivacy wrote:
| The guidelines are there to guide and mostly folks try to
| abide. I'd agree this is a case where a useful edit is the
| better option.
| nickthegreek wrote:
| I like the edit. That dull blog title would get ZERO
| traction.
| mynameisash wrote:
| Caveat that I'm by no means educated about WEI, the actual
| title feels a bit Orwellian to me. I just wanted to point
| out the actual title and not an editorialized one (without
| commenting on whether editorialization is good or bad
| here).
| rezonant wrote:
| In case this is all new to you: effectively WEI aimed to
| bring hardware-based remote attestation to the web for
| the purposes of allowing servers to refuse service when
| the device and its software was not approved by the
| authors of the server.
|
| Now they just want to do it in WebViews, which is
| ineffectual at best, and still harmful at worst.
| fsckboy wrote:
| but if the title is "Increasing trust for embedded media",
| where's the intent to back off? The changed title implies
| everybody can stop worrying.
| endisneigh wrote:
| It's funny how techies complain about clickbait yet
| celebrate and engage with... clickbait
| whatshisface wrote:
| We just want the headlines to somehow reflect what we
| will see if we click on them.
| digging wrote:
| I don't think you know what clickbait is, because
| "accurate description of the main content" is not
| clickbait.
| spitfire wrote:
| "Google apparently backs off on WEI."
|
| For the time being.
| Loudergood wrote:
| Good.
| lol768 wrote:
| WEI itself was previously discussed across a number of threads,
| which make interesting reading:
|
| (July 2023, 456 comments)
| https://news.ycombinator.com/item?id=36854114 - "Google's
| nightmare Web Integrity API wants a DRM gatekeeper for the web"
|
| (July 2023, 431 comments)
| https://news.ycombinator.com/item?id=36817305 - "Web Environment
| Integrity API Proposal"
|
| (July 2023, 434 comments)
| https://news.ycombinator.com/item?id=36875940 - "Unpacking
| Google's Web Environment Integrity specification"
|
| (July 2023, 111 comments)
| https://news.ycombinator.com/item?id=36857676 - "So, you don't
| like a web platform proposal" - Google employee's view on how
| folks _should 've_ responded to the proposal
|
| (August 2023, 100 comments)
| https://news.ycombinator.com/item?id=36960882 - "Web Environment
| Integrity: Locking Down the Web"
| jjoonathan wrote:
| Oof, that hyper-aggressive whitewashing of the DRM proposal
| from yoavweiss_ was a harsh lesson in realpolitik. Nerds were
| bringing good faith arguments to a bad faith optics war and
| getting slaughtered.
| belval wrote:
| For people wondering which of the links to click:
| https://news.ycombinator.com/item?id=36857676
|
| It's mostly just the classic "nono if you don't agree it's
| because you don't understand" and "please educate yourself"
| approach.
| whatshisface wrote:
| At least they didn't try, "I don't have time to educate you
| about why you're bad!"
| mcpackieh wrote:
| > _" P.S. I'd love to discuss this with y'all like
| professional adults. Can we do that?"_
|
| You can tell somebody is a snake when they aren't from the
| South but use _" y'all"_. It's become a sort of corporate
| snake shibboleth.
| jkaplowitz wrote:
| Meh, it spreads a lot more broadly than the corporate
| snake people. And honestly I've never heard the corporate
| snakes use it myself (at least not before the example
| which you quoted), but I'm sure there are corporate
| snakes who do.
| duxup wrote:
| I certainly think that a lot but I sure as hell wouldn't
| say it. It doesn't help, that discussion never goes well.
| dmoy wrote:
| Uhhh, what?
|
| I use y'all 'cus that's how all the kids in my school
| talked growing up.
|
| I ditched a lot of the lexicon because after my family
| moved to the suburbs, I got made fun of by my new
| friends, literally calling me "less white". So no more
| finna', for example.
|
| I will die on the hill of having a good second person
| plural pronoun though.
| ethbr1 wrote:
| Once you've used English with a second person plural
| pronoun, you can't go back.
|
| PS: "Yous guys" doesn't count
| JohnFen wrote:
| "y'all" is a bit fraught in the US because (incorrectly,
| in my opinion), in some parts the use is associated with
| certain unflattering cultural stereotypes. Not usually
| racial ones.
|
| > I will die on the hill of having a good second person
| plural pronoun though.
|
| I'm with you there -- we really need one, but I haven't
| found one that is broadly safe to use.
| mcpackieh wrote:
| If you actually grew up using it, then you're not who I'm
| talking about. The word, like "folks", has become part of
| the affected dialect used by corporate ass-kissers to
| tell other corporate ass-kissers what they're about. Used
| primarily by slimy management, HR and PR types.
|
| These types do not say finna, that isn't part of this
| affected dialect. If you say finna then you're not who
| I'm talking about.
| mixmastamyk wrote:
| Looks like yoavweiss was slaughtered, not the good-faith
| nerds.
| wkat4242 wrote:
| I don't think they were. After reading this my view of this
| person is just a corporate drone. Obviously this proposal is
| to serve the content owners, not the users, whatever the
| thoughts behind it are. And yes it may not be intended to
| block adblockers but it certainly can easily be used for that
| once it's ubiquitous. Attestation which is basically what
| this is, _always_ implies a move of some measure of control
| from the user to the content or service provider. It exists
| purely because they don 't trust the user. There is just no
| way this would have ended positively.
|
| And why would I go into discussion with Google? They don't
| own the web and never will. And their business model means
| they (and their employees) will always be my enemy because
| their goals are opposite to my own. I can criticise but it
| doesn't have to be constructive. A "Just NO" is fine too. I
| would be very happy with a world where Google doesn't exist.
|
| But in this case the nerds won which means the way it was
| done worked perfectly fine. Perhaps they will have stepped on
| a few toes at Google but I'm kinda glad to hear that.
| thaumaturgy wrote:
| Even more simply: let's not get dragged into debating the
| technical merits of something which is _philosophically
| wrong_. That particular person was trying really hard to
| reframe the whole argument into terms that would work in
| Google 's favor -- if we just pointed out what was
| _technically_ wrong with the proposal, why, they 'd just
| fix those things and then we'd be good to go. But, it was
| _philosophically wrong_ , because we've all understood the
| web to be fundamentally open and anonymous and not
| controlled by any one entity [1] for decades and most of us
| want it to stay that way. Even if WEI was technically
| sound, it would still be an enormous erosion of the
| principles of an open, anonymous, decentralized web. Any
| attempt to argue against WEI on its technical merits alone
| was just allowing Google to drag the whole fight into
| favorable territory.
|
| > _And why would I go into discussion with Google? They don
| 't own the web and never will._
|
| Oh, I think this is a big mistake. Google very nearly
| _does_ own the web. Gmail handles, at last estimates,
| between 45% and 60% of email traffic, depending on who you
| talk to. Chrome or Chromium gets somewhere around 65% of
| the global browser market. Google gets around 90% of search
| traffic. Google ads. Google domains. YouTube. Google Cloud,
| which WPEngine for example runs on. Google Docs.
| Chromebooks. Android.
|
| I really need more people to pause and reflect for a moment
| on just how much of the internet is currently owned by
| Google.
|
| [1]: Well, ignoring ICANN, or Microsoft, or Google, or
| Cisco, or...
| msla wrote:
| So we can take that yoavweiss_ character as a Google
| representative.
| dylan604 wrote:
| if it walks like a duck, and it quacks like a duck, it must
| be a...
| mikestew wrote:
| This person does not hide the fact that they work for Google
| (at least that's why take from their about page), so yes,
| they represent Google. Because if there's anything that was
| beaten into me in my time at Microsoft, it's that you can put
| all the "views are my own" in your posts you want, but
| probably most people that read your post will take you to
| represent $COMPANY's views no matter the disclaimers.
| hanniabu wrote:
| Doesn't matter, they've already showed their hand with how
| they're wiling to ignore everyone and try to push through
| whatever they want.
| endisneigh wrote:
| They've shown their willingness to ignore by... scrapping
| something that was disliked?
| hanniabu wrote:
| I imagine they're pulling the politician card. When there's a
| lot of pushback, you scrap it for optics, and then a few
| months or years later you bring it back under a different
| name and presented as something new and hope people don't
| pick up on it. And if they do, then you repeat until people
| are exhausted enough to not give any pushback anymore.
| teddyh wrote:
| A.k.a. "Outrage fatigue".
| ls612 wrote:
| Google has been claiming to want to break adblockers (although
| they don't put it that way) with Manifest v3 and removing
| Manifest v2 for a while and they have always backed off
| actually pulling the trigger on it.
| freedomben wrote:
| TFA is about more than just WEI, but it does address it directly:
|
| > _We've heard your feedback, and the Web Environment Integrity
| proposal is no longer being considered by the Chrome team. In
| contrast, the Android WebView Media Integrity API is narrowly
| scoped, and only targets WebViews embedded in apps. It simply
| extends existing functionality on Android devices that have
| Google Mobile Services (GMS) and there are no plans to offer it
| beyond embedded media, such as streaming video and audio, or
| beyond Android WebViews._
|
| This is really great to hear, thank you Chrome team!
|
| Is there a risk that this is one of those "shelve it for 6 months
| and we'll try again later" playbooks, and that already having the
| implementation will make it just "an expansion" of existing tech
| rather than "new" tech, which will make the pill easier for most
| people to swallow even though it gets to the same end result?
| iofiiiiiiiii wrote:
| What does your heart tell you? Palladium[1] came and went and
| then suddenly most laptops and mobile devices have a built-in
| TPM today. No doubt history will repeat.
|
| [1] https://en.wikipedia.org/wiki/Next-
| Generation_Secure_Computi...
| jorvi wrote:
| Uhm... what?
|
| Your beef is with things like Pluton, Intel's ME and AMD's
| PSP.
|
| TPM at their base are nothing else than a more secure place
| to store cryptographic data.
| JohnFen wrote:
| It's a place that applications can store such data without
| my knowledge or control, and I don't trust applications
| enough to be comfortable with them having that ability.
|
| Don't get me wrong, it's not a major issue for me, it's
| just uncomfortable. It just means I prefer my machines to
| not have TPM hardware in them.
| Arainach wrote:
| I don't trust applications enough to have things like the
| encryption key for my hard drive outside a TPM.
| marklar423 wrote:
| I don't disagree, but how do you feel about you (the
| machine owner) also not having access to it?
|
| That's my major problem with it; it locks you out of
| messing with your own machine data, which you can see
| being instantly abused by third parties to prevent
| modifications.
| acdha wrote:
| That feels wrong in some ways but it's also the only way
| you can trust used hardware, or anything which has been
| compromised. I do get considerable value out of the
| resale value for my stolen Apple devices being much
| lower, and that's probably a higher risk for most people.
| josephg wrote:
| TPM chips are pretty open. I had a look through the spec
| & API for tpm 2.0 a few years ago and there's a lot of
| neat tricks you can do with them. TPM chips are an open
| standard with many implementations.
|
| As far as I can tell, as a software developer you have
| full access to the chip. The only thing you can't do with
| them (by design) is read the signing keys or generate
| secure boot attestations for machines which didn't secure
| boot. I think you can even replace the signing keys
| entirely if you want to.
|
| They aren't a hard drive. They don't store your data. And
| unfortunately I don't think they'll do much to prevent
| software bugs from causing problems. Particularly in the
| operating system, where software bugs can undermine the
| entire chain of trust model.
|
| Don't get me wrong; the idea of getting my computer to
| cryptographically prove it's running in some locked down
| Xbox mode to be allowed to play Netflix or do online
| banking is quite the ask. The hackability of computers is
| one of their best features and I don't want that genie to
| go back in the bottle.
|
| But every time the conversation comes up there's so much
| misinformation about them. People conflate tpm chips with
| intel's management engine (which is secret and closed
| source), Apple's secure enclosure (which I think can
| store some data?) and other stuff that works really
| differently.
| JohnFen wrote:
| > The only thing you can't do with them (by design) is
| read the signing keys
|
| That's why it makes me nervous.
| gray_charger wrote:
| > That's my major problem with it; it locks you out of
| messing with your own machine data, which you can see
| being instantly abused by third parties to prevent
| modifications.
|
| It locks everybody, including the owner, out of any data
| it doesn't own. That's the point. If you can pull it out,
| so can anybody else, and you've just made a small hard
| drive. Could it be used by vendors for DRM-like things?
| Sure. That's on the vendor, though, and not the
| technology itself.
| JohnFen wrote:
| > That's on the vendor, though, and not the technology
| itself.
|
| And that's the problem. I have little actual trust of
| vendors anymore. Too many bridges have been burned to
| trust by default.
| Angostura wrote:
| I'm not storing my fingerprint anywhere else.
| matheusmoreira wrote:
| The problem isn't the cryptography, who's using it and
| for what. There's nothing wrong with it if we're using it
| to empower and secure ourselves. There's everything wrong
| with it if it's some corporation using it to protect
| themselves from us, the owners of the machines. The
| former is just normal user activity. The latter means our
| computers are not really ours, they come pwned straight
| off the factory.
| rezonant wrote:
| They can _store_ that data, but they cannot _retrieve_
| that data. That 's because the data it stores are
| cryptographic secrets (private keys). If they store a
| private key there and then delegate encryption/decryption
| to the TPM, you can also ask the TPM to perform said
| encryption/decryption using that key as the system owner.
|
| The entire point of a TPM is ensuring that private keys
| intended for a specific device are never leakable off of
| that device.
|
| Now that being said, there _is_ an additional function of
| TPMs that is more controversial, and that 's how it can
| be used by the CPU and firmware to refuse to execute code
| when a chain of attestation coming from a root key stored
| in the TPM is not satisfied. That controversy is very
| valid for TPMs or other "enclave" devices which do not
| allow the system owner to change those root keys. And of
| course there is the extended ability to leverage this
| attestation over a network, to allow a _server_ to be
| able to refuse service if the attestation is not valid.
|
| When the user can change the root attestation keys, I
| think local attestation is a net positive for the
| security of the user. When they cannot, it means that
| only the "blessed" builds from the hardware manufacturer
| can run. This second case should be made illegal in my
| opinion.
|
| Though there's nuance here, remote attestation however is
| a net negative for the user. Taken to it's logical
| conclusion where unattested access is 100% refused
| without exceptions, it means that the user _effectively_
| cannot run their own software on devices that they own,
| and that is not acceptable. It also ensures that the user
| can only use hardware devices that the service provider
| deems as allowed, which is the more practical and likely
| outcome at scale.
|
| Remote attestation is what's at issue with WEI (and
| indeed things like Google Play Integrity and the
| equivalent feature of Apple's iOS stack), not the ability
| to ensure that private keys cannot be leaked.
| JohnFen wrote:
| > They can store that data, but they cannot retrieve that
| data.
|
| Right, which means software can engage in encryption that
| I can't decrypt because I can't get the keys.
|
| You're right, RA (when the user can't change the keys) is
| a much more concerning thing. It can be used to prevent
| me from exerting full control over my own hardware.
|
| My problem with TPM isn't really the TPM itself, it's
| that I have very little trust in software and so want to
| be able to keep a close eye on it and audit things as
| needed. I want to be able to do things like decrypt data
| streams sent over the wire, etc.
|
| And, as I said, this is a relatively minor thing for me.
| Even writing as much about it as I have puts more
| emphasis on it than I would prefer. In practice, the
| majority of the software that I use doesn't even want to
| use the TPM, so it's all good.
| RockRobotRock wrote:
| Yeah. Intel SGX seems kinda similar and is or at least was
| used for DRM.
| appleskeptic wrote:
| Don't forget that the anti-TPM stuff comes from the guy,
| RMS, who opposes "sudo" because it serves to let a machine
| owner control and audit use of super-user commands, whereas
| just having a root password shared by multiple users gives
| anyone who learns the password the freedom to do whatever
| they want with plausible deniability. He has a very strange
| and quaint way of thinking but people uncritically parrot
| him without appreciating what his world-view actually
| entails.
| clowncity wrote:
| Right, the man responsible for all computing freedom,
| that guy right? Cool. If he hates it, then so do I.
| claytongulick wrote:
| Given that RMS has a pretty good track record or
| predicting the kinds of abuses that we're seeing today,
| it seems like a good idea to at least pay attention to
| his ideas and not dismiss them out of hand.
|
| Also, you know, GNU.
| alexjplant wrote:
| For those that would appreciate context: Stallman did say
| this but the incident that he cites as justification
| happened _four decades ago_ and he wrote about it in 2002
| [1]:
|
| > Sometimes a few of the users try to hold total power
| over all the rest. For example, in 1984, a few users at
| the MIT AI lab decided to seize power by changing the
| operator password on the Twenex system and keeping it
| secret from everyone else. (I was able to thwart this
| coup and give power back to the users by patching the
| kernel, but I wouldn't know how to do that in Unix.)
|
| > However, occasionally the rulers do tell someone. Under
| the usual su mechanism, once someone learns the root
| password who sympathizes with the ordinary users, he or
| she can tell the rest. The "wheel group" feature would
| make this impossible, and thus cement the power of the
| rulers.
|
| > I'm on the side of the masses, not that of the rulers.
| If you are used to supporting the bosses and sysadmins in
| whatever they do, you might find this idea strange at
| first.
|
| He was talking about a time-sharing system in an academic
| context. We have no idea what his thoughts are now, and
| it's logically fallacious to discount his feelings on
| what multinational corporations bake into their silicon
| on the basis of an experience that he had back when Van
| Halen was still topping the charts. It isn't exactly a
| secret that RMS is a bit "out there" - lots of
| historically-significant people are. Contextualizing
| their work and speech in a constructive way is preferable
| to writing them off wholesale.
|
| [1] https://ftp.gnu.org/old-
| gnu/Manuals/coreutils-4.5.4/html_nod...
| userbinator wrote:
| _TPM at their base are nothing else than a more secure
| place to store cryptographic data._
|
| One which you, as the owner, don't have the keys to.
| vlovich123 wrote:
| If you use a mobile device maybe. My desktop machine has
| a TPM and AFAIK I do have access to load my own keys /
| replace the root keys. Of course, nothing says there
| isn't a backdoor within the TPM, but it's not this secret
| locked down thing.
| cryptonector wrote:
| It's unlikely that there is a backdoor on the TPM itself.
| The more likely scenario is that given a TPM serial
| number or EKpub the vendor could furnish a seed in
| response to a subpoena or warrant -- however, even this
| is unlikely, as it would make TPM vendors huge targets
| for hacking. Also TPM vendors make a big deal of how they
| don't keep TPMs' seeds, and I tend to believe them,
| because again if they did keep them then they'd be huge
| targets.
| mcpackieh wrote:
| "Crypto AG's products being compromised is extremely
| unlikely, because that would make them a huge target."
| gray_charger wrote:
| > One which you, as the owner, don't have the keys to.
|
| One which nobody, not even the owner, can extract keys
| from. I don't understand why people don't like the fact
| that they can't pull keys out of the TPM. If you, the
| owner, can pull them so can anybody else. I know TPMs
| aren't invulnerable but you have to admit they
| significantly raise the bar of compromise.
| cryptonector wrote:
| What do you mean specifically?
|
| You _can_ : - set passwords on the key
| hierarchies - roll the seeds for the key
| hierarchies, thus invalidating *all* keys on the
| TPM
|
| Now, Windows might stop working if you do that, and
| naturally, if you wanted to use a TPM for locking your
| filesystems then you'll need to do this _before_ you
| install your OS.
|
| Also, once you change the seed for the Endorsement Key
| hierarchy you'll lose the ability to prove that the TPM
| is a legit TPM made by whatever legit TPM vendor.
|
| So sure, this is only something you do if you know what
| you're doing, especially if the TPM is soldered onto the
| motherboard.
| raverbashing wrote:
| Yes and according to discussions at that time Palladium would
| be always on, on all PCs and it would banish Linux from all
| PCs making Windows the some possible OS..
|
| Which is totally what happened, right? /s
| userbinator wrote:
| _and it would banish Linux from all PCs making Windows the
| some possible OS_
|
| We're getting closer to that with things like "secure"
| boot. Fortunately that can still be disabled, but MS even
| required that on ARM platforms it can't. The bigger Linux
| distros have bent over and gotten MS to sign their
| bootloaders, essentially making them at the mercy of MS.
| c0pium wrote:
| This is a weird way to describe an open, transparent
| standard.
|
| https://wiki.debian.org/SecureBoot#What_is_UEFI_Secure_Bo
| ot_...
| LoganDark wrote:
| It doesn't matter how open and transparent the standard
| is if part of the de facto implementation is that
| Microsoft is the only one with the keys.
|
| Some BIOSes let you enter your own Secure Boot keys (like
| my desktop and laptop), but not all.
| Analemma_ wrote:
| I've complained about this before, but I've been hearing
| "Microsoft is going to block you from installing Linux!"
| since like 2004, when it was a reliable way to get an
| easy "+5 Insightful" on Slashdot. It hasn't happened,
| even on Microsoft's own first-party computers.
|
| At this point I think it's firmly FUD and the people who
| say it's coming any second now need to put up the
| evidence. Microsoft doesn't seem to care, especially now
| that Windows is an afterthought to Azure, O365, etc.
| trinsic2 wrote:
| If you keep track of the changes to the BIOS firmware,
| you can see the changes. Their minuscule but happening.
| We don't have full blow preventing from disabling secure
| boot yet, but it appears to me that's were this is going.
| (Disabling usb ports, having keys that prevent disabling
| Secure boot unless you clear them or change them. All it
| takes is some event to bring these companies over the
| edge. The Asus MB development relies totally on
| Microsoft's decisions about this.
|
| I think the point, at least for me, is that they
| shouldn't be taking away any user control for consumer
| products. And yet that is what we have let them do. Its
| not going to stop.
| cesarb wrote:
| > > I've complained about this before, but I've been
| hearing "Microsoft is going to block you from installing
| Linux!" since like 2004 [...]
|
| > If you keep track of the changes to the BIOS firmware,
| you can see the changes. Their minuscule but happening.
| We don't have full blow preventing from disabling secure
| boot yet, but it appears to me that's were this is going.
|
| Case in point: until recently, even with SecureBoot
| enabled by default, you could boot Linux distributions
| which have their bootloader signed by Microsoft, without
| going into the firmware setup screen. Nowadays, at least
| with some Lenovo models, you have to go to the firmware
| setup screen, and either enable a cryptically named
| option or disable SecureBoot. A quick web search gave me
| https://www.omglinux.com/boot-linux-modern-lenovo-
| thinkpads-... which has a screenshot, and which mentions
| that this is a new Microsoft requirement (instead of
| something Lenovo came up with).
| pzmarzly wrote:
| Back when EFI consortium wanted to make Secure Boot
| always on, it wasn't even clear if ARM is going to win in
| mobile market, let alone PC/server one.
|
| Nowadays all non-mobile aarch64 devices I used, and even
| many mobile ones, let you boot your own unsigned kernel.
| Arm's SBBR only states that IF you implement Secure Boot
| and TPM support in your EFI firmware (you don't have to),
| it has to comply with certain rules. Nothing about
| preventing users from disabling it.
| (https://documentation-
| service.arm.com/static/5fb7e66fd77dd80...)
| lagrange77 wrote:
| Hallelujah
| mixmastamyk wrote:
| > Is there a risk that this is one of those "shelve it for 6
| months and we'll try again later" playbooks...?
|
| Odd way to phrase a sure thing. The "war on general purpose
| computing" is real and fought continuously by the powers that
| be. I believe Doctorow has one of the important works on the
| subject.
| nonrandomstring wrote:
| It'll be back, in another form.
|
| Pay no attention to specific projects and proposals that are
| offered and withdrawn. Look at the bigger picture over a longer
| time-frame and ask; what are the forces acting within and upon
| an entity?
|
| Meadows' leverage points taxonomy can be used analytically as
| well as instrumentally. What are the _values_ behind
| misadventures like WEI ?
|
| Google want to own your browser and infiltrate as much of the
| client-side as they can.
|
| What other technical avenues and regulations can they make
| politically expedient use of?
|
| To fight this abuse don't attack proposals, projects, or even
| behaviours. Study and attack their core values. What are they
| really about?
| mlyle wrote:
| Sometimes what you're describing is a valid approach-- once a
| pattern is clear. This is looking pretty reasonable for
| Google.
|
| But it seems like a bit of a toxic, pessimistic response in
| general.
|
| There's other times where a party just screws up. e.g.
| Apple's CSAM-- once the industry educated them, they took a
| very different tack. There was no fundamental structural or
| cultural issue pushing them towards the problematic choices.
| wkat4242 wrote:
| > There's other times where a party just screws up. e.g.
| Apple's CSAM
|
| Did Apple really screw up? Their proposal is pretty much
| what the EU and UK governments want now :(
|
| I think they screwed up because to have my own phone spying
| on me is unthinkable and I would never have considered
| another Apple product again. But politics seem to like the
| idea.
| PaulHoule wrote:
| Those governments are mostly coming around as to why
| that's a bad idea.
| wkat4242 wrote:
| I don't think so, I think they're just regrouping to find
| another approach to push it through.
| nonrandomstring wrote:
| > But it seems like a bit of a toxic, pessimistic response
| in general.
|
| I'm a twisted firestarter, but it's mostly out of a
| passionately optimistic and generous view of other human
| beings. Big corporations are not human beings. I think they
| fail humanity. They have too much power and no
| accountability. For that I think they deserve all the
| toxicity and pessimism fitting for what they are.
| ZeroCool2u wrote:
| The title is misleading. They've dropped the proposal as applied
| to Chrome, but are still pursuing it for the Android WebView API,
| which is basically a wrapper around Chrome.
| andybak wrote:
| Webviews are particularly vulnerable though, being used for
| embedded logins for sometimes dubious 3rd party apps.
|
| Is there a reasonable angle to view this from?
|
| I personally don't think embedded webviews should be allowed
| general browsing capability unless they are part of a
| standalone browser.
|
| It's usually a trick to capture traffic that would otherwise go
| off to the open web.
| TremendousJudge wrote:
| If that's the problem you're trying to solve, disallow
| embedded ~~logins~~ webviews and do it through a proper
| browser, same as on a regular computer. The other way seems
| overkill and smells like foul play to me.
| andybak wrote:
| I'm not sure how you disallow embedded login without
| disallowing embedded webviews. The line is very blurry.
| TremendousJudge wrote:
| I'm sorry, I wrote embedded logins but was thinking
| embedded webviews in general. The only legitimate use of
| that in my mind is "a web browser app that's a usability
| skin over Chrome". Everything else is just a way of
| keeping you in a walled garden, and would be better if it
| just sent you to your default browser.
| andybak wrote:
| Ok. So I think we are in agreement. I struggle to think
| of a use case that is in the user's best interests.
| londons_explore wrote:
| You have two types of webviews... "Webviews to the
| appmakers server", and "Webviews for the wider web".
|
| Webviews to the appmakers server need to be authorized by
| some manifest file on the server whitelisting the app
| identifier.
|
| Webviews for the wider web don't allow the app to know
| what's going on inside the webview, nor interact with it.
| So these are safe to type passwords into etc.
| claytongulick wrote:
| > disallow embedded logins and do it through a proper
| browser
|
| How would you propose doing this from a technical
| standpoint?
|
| How is android supposed to know what an embedded login is
| on a web page?
|
| What happens when you're in an SSO or other secure
| environment and need to refresh credentials after a
| redirect?
| Obscurity4340 wrote:
| Is Friendly Social Browser maybe a good solution to this
| problem?
| IshKebab wrote:
| > being used for embedded logins for sometimes dubious 3rd
| party apps.
|
| That's a difficult problem to solve though. To do it properly
| you'd need something like Windows' secure key sequence (ctrl-
| alt-del) which apps can't intercept. Otherwise there's no way
| that a user can know that what they're seeing is the system
| rather than a malicious app.
|
| Consider that any app can embed any browser or UI that they
| want.
| londons_explore wrote:
| That exists on mobile though... They could easily have a
| "swipe down to login" gesture, where you would see some
| system UI saying "Appname wants your password to foo.com,
| do you want to allow the app to log in using your saved
| password?".
|
| foo.com could also cooperate and allow the message to say:
|
| "Appname wants to 'send pokes' on foo.com, do you want to
| allow this?" - allowing the app a scoped login to only
| specific actions.
| endisneigh wrote:
| It's interesting that a single googlers repository was what was
| being used for wei discussion instead of something more
| "official".
|
| People celebrating this aren't realizing that it'll probably stop
| api scraping via a web view back door.
| dylan604 wrote:
| This way, they can hide it in another repo later
| harshitaneja wrote:
| I have been walking around with this dread ever since the
| proposal was announced. Thinking about its implications made me
| appreciate even in today's screwed up internet we still don't
| have it that bad.
| _Algernon_ wrote:
| ... (for now)
| sarahdellysse wrote:
| > backed off WEI
|
| for now
| londons_explore wrote:
| > Android WebView Media Integrity API is narrowly scoped
|
| I don't see any benefit to the user... Surely any app which
| wishes to embed a webview can simply add an api to said webview
| with native code to use existing android integrity API's?
|
| To me, this looks like a backdoor way to prevent people making
| "hacked" apps which, for example, play youtube but without ads.
| This API doesn't benefit the users.
| JohnFen wrote:
| It's not intended to benefit the user.
| ugh123 wrote:
| The benefit to the user is they can supposedly "trust" the
| content that is being shown in the webview is, in fact, owned
| by or affiliated somehow with the app. They don't give an
| example, but i'd imagine its something like: "bad app lets
| user's sign into their bank account through the app's
| webview, then webview scrapes/intercepts content to do as
| they wish".
| ethbr1 wrote:
| Isn't that something that should be solved at the App Store
| and/or application fraud detection levels?
|
| I get bad actors exist.
|
| But they're not an excuse to strip everyone else of rights.
|
| >> _The Android WebView API lets app developers display web
| pages which embed media, with increased control over the UI
| and advanced configuration options to allow a seamless
| integration in the app. This brings a lot of flexibility,
| but it can be used as a means for fraud and abuse, because
| it allows app developers to access web content, and
| intercept or modify user interactions with it._
|
| This proposal was always a stick of dynamite when a
| screwdriver was needed.
|
| Start with the assumption that a user client should be able
| to do whatever the user decides it should. And while
| keeping that in mind as an absolute, work backwards.
|
| If it creates false ad clicks... tough. Deal with it.
| c0pium wrote:
| And if it drains people's bank accounts because they
| aren't savvy enough to know that their bank's app is
| realbank not realbankofficial? Deal with it?
|
| The stance that other people should have their savings
| stolen, when we could have easily stopped it, because of
| nebulous freedom reasons is pretty ghoulish.
| JohnFen wrote:
| Perhaps the solution is to have two classes of machines,
| some "safe" for those who don't want to (or can't) be
| proactive and alert to security threats, and some
| "unsafe" for those who want total control over their
| machines and are willing to take on the security risks
| and responsibilities to do that.
| jasonjayr wrote:
| I mean, yes. 1000% yes.
|
| But the reality is that the 'market' will push to only
| make content for the "safe" machines, and the total
| control folks will slowly get locked out.
|
| Banks have required auditors that will mandate only
| allowing access from 'safe' environments Media companies
| will do everything to make sure content is only played in
| 'safe' environments Government will allow allow you to
| interact with their technology from 'safe' environments,
| etc.
|
| And they will all believe 100% they are doing the right
| thing to protect the users.
|
| I am deeply afraid for open general purpose computing.
| ndriscoll wrote:
| If they installed it through a commercial app store, hold
| the store owner liable as an accessory to fraud.
| londons_explore wrote:
| They could protect against that easily by simply adding a
| header to all outgoing requests saying "this request
| originated from com.appname".
|
| If a website didn't want to be embedded in that app, the
| webpage could refuse to let the user log in.
|
| The whole thing is a bit moot, because any app can just
| implement their own web renderer or just fake the login
| screen to Chase.com entirely to get the users creds.
| josteink wrote:
| > The benefit to the user is they can supposedly "trust"
| the content that is being shown in the webview is, in fact,
| owned by or affiliated somehow with the app.
|
| You got it backwards. The user gets to trust nothing.
|
| The "trust" in this case is for the server to asses if it a
| trusted (not hacked/hackable) environment to deploy content
| to.
|
| DRM is the only use case.
| c0pium wrote:
| This is incorrect. If Chase uses attestation then only
| the Chase app can access their login site. It prevents
| DefinitelyChaseAndNotMalware from masquerading as Chase.
| happytiger wrote:
| DRM schemes, especially when they masquerade as public
| service, rarely are.
| ajross wrote:
| > To me, this looks like a backdoor way to prevent people
| making "hacked" apps which, for example, play youtube but
| without ads.
|
| More like "impersonate your bank and steal your login
| credentials". MitM attacks using interposed clients are a
| genuine threat outside the Apple and Google walled gardens (and
| even a little bit within). WEI was an attempt at solving a real
| problem.
|
| Now, maybe it had unacceptable side effects, maybe it was more
| harmful than useful. And now it's dead. But the underlying
| issues got completely lost in the hyperbole wars around here.
| People were wildly slinging accusations of secret agendas and
| general bad faith[1]. It wasn't our finest moment as a
| community.
|
| [1] Most of them while typing said comments on an Apple device
| objectively even less friendly to nonstandard clients!
| c0pium wrote:
| You're being downvoted at the moment, but this is absolutely
| true. Fake bank apps are a huge problem, which this
| addresses.
| amalcon wrote:
| It seems pretty straightforward to prevent that anyway, through
| Play Integrity attestation. This just makes it easier to do
| with a webview-based app.
| pshirshov wrote:
| > In contrast, the Android WebView Media Integrity API is
| narrowly scoped
|
| I guess it means that at some point I won't be able to use many
| apps under GrapheneOS with its Vanadium WV?
| jwr wrote:
| I expect to see the usual Google approach: back off, then come
| back with another take on the same thing, but wrapped
| differently.
| TremendousJudge wrote:
| They have been tamed in the past. Correct me if I'm mistaken,
| but Google Native Client was completely discontinued and wasm
| was adopted eventually. I see that as a victory for the open
| internet.
| KMag wrote:
| I'm not sure WASM is markedly different from PNaCL, other
| than using SSA-based LLVM bitcode instead of a stack-based
| bytecode.
| the_duke wrote:
| It's a well-defined standard with lots of different
| implemenetations, instead of "whatever Chrome does", tied
| to one specific codegen backend.
|
| That's a huge difference.
| user3939382 wrote:
| They learned it from Congress.
| vsgherzi wrote:
| Glad to see the chrome team listening to feedback
| pkaye wrote:
| Can anyone summarize what WEI is an why its bad?
| zarzavat wrote:
| DRM for web browsing. A website would be able to request an
| attestation that your browser is "trusted", i.e. it is secure
| and unmodified. Because some systems are by definition
| untrusted, e.g. Linux, or Firefox compiled from source, these
| users might be blocked from certain websites. At least that
| seemed like the intention, otherwise what's the point of
| building such a feature?
| keepamovin wrote:
| This is really good. Google did the right thing. We don't need to
| thank them for acting the way they should have originally, but we
| can appreciate it.
| cmrdporcupine wrote:
| Sorry Google, too late, already switched to Firefox.
| mplewis wrote:
| I notice that this post's title hasn't been edited by HN mods for
| "editorialization." Why not?
| i-am-gizm0 wrote:
| Official confirmation in the WEI public discussion thread:
| https://groups.google.com/a/chromium.org/g/blink-dev/c/Ux5h_...
| wkat4242 wrote:
| Great. Really dodged a bullet there.
| imiric wrote:
| Not really. More like the entity pointing the gun has now
| decocked it.
|
| The scary part is that there is a single entity with that
| kind of power to begin with. It's a testament of the failure
| of the modern web, and how far it has strayed from the
| original spirit of the internet.
| happytiger wrote:
| This is the point. Let's celebrate a reduced scope
| implentation on a more limited number of platforms until we
| perfect the technology? No. Not really a victory. Just a
| pause.
| skydhash wrote:
| Mostly because most people don't care about the original
| spirit of the internet. As long as they can get their job
| done, consume entertainment, and play status game, they are
| content. Which is why for most people, their internet is
| just a handful of tech companies. It's basically Minitel,
| but fueled by ads.
| phoronixrly wrote:
| They are still making it easier for developers to create apps
| that limit what you can do with your own hardware.
| wkat4242 wrote:
| Yeah I wish they would not have.
|
| However, it does eliminate this issue for 90% of my
| usecases. The apps that will want to do this stuff I
| probably won't even want to use anyway.
| ok123456 wrote:
| For now.
| m-p-3 wrote:
| Until next time, for the sake of the open Internet we can't stop
| pushing back. It's exhausting.
| rezonant wrote:
| Never back down, never what!
| morkalork wrote:
| It only took "privacy sandbox" what two, three years too cool
| off before it was rolled out to everyone? They're a big
| company, they'll wait you out.
| sgammon wrote:
| We did it. Massive hckrnews W
| wkat4242 wrote:
| Wow that surprises me. A lot.
|
| I'm sure they will cook up something else evil though. FLoC just
| came back under a different name.
|
| It is so surprising to me that the one company that had "don't be
| evil" in their motto has become the one most antagonous company
| to society (or at least in a digital services manner, I'm sure
| Palantir and Monsanto can take that crown in their own areas).
| exabrial wrote:
| Reading between the lines:
|
| They're leveraging their monopolistic position to force APIs into
| an "open source" project to prevent users from skipping ads.
| rezonant wrote:
| This blog post is how they should have _started_ the discussion
| about WEI, but better late than never.
|
| That being said, while I can somewhat understand the use case for
| preventing fraud, misconception of source, etc, what we're
| talking about effectively kneecaps the ability to write bonafide
| Android browsers that leverage the WebView engine, while doing
| little to prevent the fraud and abuse the proposal intends to
| solve.
|
| If you are an Android browser author, you certainly can ship your
| own browser engine, unlike on Apple's platforms where that's
| still prohibited. However, if your motivation for creating that
| browser is primarily around the user experience or other "over
| the top" features, building your own browser engine simply
| because WebView cannot operate as a real web browser to your
| users, is unfortunate.
|
| Meanwhile, as an app developer who is interested in engaging in
| fraud, misinformation, or other nefarious things, they _can_ ship
| their own browser engine to bypass this functionality entirely.
| Does it add more work? Yes, but if their goals include this bad
| behavior, why wouldn't they?
|
| Even without all this, assuming that Chrome itself, Firefox nor
| anyone else will actually implement some kind of "this is
| definitely not a web view" attestation, the content owner has no
| choice but to allow that access, since they have no idea if the
| user agent they are looking at is a legitimate browser or an
| embedded webview.
|
| Google, there is no way to solve this problem using attestation
| short of the original WEI proposal, which is bad for users. All
| you are doing now is muddying the waters and adding _some_ harm
| instead of _a lot_ of harm.
| nolist_policy wrote:
| Sure, malware can ship its own browser engine but it can not
| attest authenticity to the _server_.
|
| The proposal doesn't limit the Android WebView in any way.
| jader201 wrote:
| Original title:
|
| "Increasing trust for embedded media"
|
| > _Otherwise please use the original title, unless it is
| misleading or linkbait; don 't editorialize._
|
| https://news.ycombinator.com/newsguidelines.html
| digging wrote:
| The original title is misleading.
| ethbr1 wrote:
| The original title is misleading enough to be incoherent.
| phoronixrly wrote:
| This title is also misleading. Google backs off on WEI in
| Chrome, but still pushes it in the webview, thus making it
| easier to create apps that limit what you can do with your
| own hardware.
| Wowfunhappy wrote:
| I don't understand how this works.
|
| > The new Android WebView Media Integrity API will give embedded
| media providers access to a tailored integrity response that
| contains a device and app integrity verdict so that they can
| ensure their streams are running in a safe and trusted
| environment, regardless of which app store the embedding app was
| installed from.
|
| But this only applies to the Android WebView API, not standalone
| web browsers like Google Chrome. Otherwise we'd be back to where
| we started with the original Web Environment Integrity proposal.
|
| But no one _has_ to use the WebView API, it 's a convenient
| option but Chromium is open source! What stops Bob the Evil
| Android Developer from compiling his own version of Chromium,
| bundling that into his app, and doing whatever malevolent website
| trickery his ink black heart desires?
|
| Put another way, if this is only built into the special WebView
| API, wouldn't a malicious developer just avoid using that API?
| nolist_policy wrote:
| All this is about attesting authenticity to the _server_.
| Wowfunhappy wrote:
| But only Android WebViews can attest their authenticity. Are
| servers going to block standalone web browsers?
|
| If they are, why even use a WebView? Just make it part of
| your app.
| KRAKRISMOTT wrote:
| Many corporate apps in e.g. banking are just
| Cordova/browser wrappers around a website.
| creshal wrote:
| A lot of "native" apps are just thin wrappers around web
| components, since it's a lot cheaper to develop.
| Wowfunhappy wrote:
| Okay, thanks. So then this truly doesn't affect websites
| at all, it's for apps which work like websites behind the
| scenes, but whose content no one is ever supposed to
| access from within a web browser anyway.
|
| I can live with that!
| ethbr1 wrote:
| Step 1: Cryptographically fingerprint an attested environment,
| for one method among alternatives
|
| Step 2: Ban the alternatives
|
| Step 3: Profit
| dools wrote:
| Title should be:
|
| "Increasing trust for embedded media"
|
| There is a guideline against editorialising in the title
| samrus wrote:
| bullying corporations once again yields results
| ilc wrote:
| Sorry big G. You lost the trust on this one.
| m463 wrote:
| Web Environment Integrity (WEI) is a controversial API proposal
| currently being developed for Google Chrome.
|
| https://en.wikipedia.org/wiki/Web_Environment_Integrity
| 867-5309 wrote:
| should firstly explain what WEI is
| sensanaty wrote:
| ...for the time being, but them being the comic-book, mustache
| twirling evil villains they are there's no doubt WEI will be
| coming back, in a even more evil package, sometime down the line.
___________________________________________________________________
(page generated 2023-11-02 23:00 UTC)