4 ms·

>then maybe that browser can ask to be added? So as soon as one such webview-based browser gets added via this hypothetical petition process, what's to stop th

>then maybe that browser can ask to be added? So as soon as one such webview-based browser gets added via this hypothetical petition process, what's to stop the Evil Nasty Malware (tm) from using the same webview library? The email's author worries about needing their webview-based browser to maintain JS engine and TLS ciphersuite equivalence with an approved browser, but that becomes trivial if the exact same webview library can be used by an approved browser and the Evil Nasty Malware. It seems to me that allowing even a single webview-based browser would go against what Google is trying to do.

kbenson 6y ago
If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser. > It seems to me that allowing even a single webview-based browser would go against what Google is trying to do. I agree. Other than it being weird to ask/need the system to use a different browser than you are using, and possibly a different browser than what you've set as default if you've set it to one Google doesn't trust for auth, nothing prevents any webview browser from acting like any other webview, and outsourcing to Chrome or Firefox for the authentication to get a good token, as long as you can use a token for full Google account login (which I don't know if you can).
- Arnavion 6y ago
  >If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser. Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me. brb writing my own browser called Chremium and petitioning Google to allow it. Apart from that I'll also publish a library that uses the guts of Chremium, called the Chremium Ombodded Framework, which can be embedded in other applications. Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
  - UncleMeat 6y ago
    > Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me. Many properties of programs are composable. Security isn't one of them. Embedded browsers sniffing credentials is an observed threat to real users.
  - kbenson 6y ago
    > Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes. I didn't say it wasn't a full, browser, so please to imply that I did, I said it was a shortcut to providing a full browser (which implies it is a full browser), and it is a shortcut compared to writing one from scratch. Bottom line, if you write software utilizing libraries in a way that is extremely close or identical to a way that other software does and that method is being blacklisted for security, expect problems. It's the same for interpreted code and app stores. For security they don't want programs that can change how they function after review, so they often disallow interpreted code and downloading code to run, and in Apple's case, require their own webview library to view remote sites because of this. They don't even allow a set of other valid webview libraries, they just draw a line in the sand and say "ours only". > Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right? Probably. Seems like a bad business plan to follow in your snarky alternate reality. A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. You might have had to trade some of the snarkiness in your example for reality, in that case.
    - Wowfunhappy 6y ago
      > Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes. Epiphany uses Webkit-GTK. In a certain sense of the word, this is indeed an off-the-shelf library, but only in the same sense that Google Chrome uses off-the-shelf Blink. Epiphany a major contributor to Webkit-GTK, and one of its largest users. Should Epiphany ban everyone else from using Webkit-GTK? I don't actually think they can, it's all open source after all. > A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. Google is probably doing some kind of ridiculous obfuscated fingerprinting. I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.
Wowfunhappy 6y ago
Am I missing something fundamental here? What is the difference between a "webview-based" browser and a browser? If you're on macOS, sure, it's pretty obvious what's a WebView, because Apple explicitly uses the term, and it's their OS. The distinction is one of language rather than technology, but it's a valid distinction nonetheless. On Linux, I don't think the distinction exists. Webkit-GTK is the Linux port of Webkit, and it can be used for anything.
- Arnavion 6y ago
  There isn't a distinction. That's my point.
  - Wowfunhappy 6y ago
    So what did you mean by "it seems to me that allowing even a single webview-based browser would go against what Google is trying to do."
    - Arnavion 6y ago
      kbenson suggested that Google could be petitioned to allow more browsers than the handful they already have. I'm saying that if they allow even a single new webview-based browser, that would implicitly also allow any program using said webview library. This is the opposite of what Google wants. Therefore the only logical conclusion is that Google will not allow any webview-based browsers. In https://news.ycombinator.com/item?id=25156594 https://news.ycombinator.com/item?id=25156594 kbenson clarified that they think Google should not allow any webview-based browsers regardless of whether this hypothetical petition process exists or not. I responded by pointing out how this distinction does not help in any way, because even a new browser written from scratch that gets allowed by Google can then turn around and implement a webview library based on itself anyway. My point is that this entire thing that Google is apparently trying is nonsensical. Maybe it works for phones, where "malware" (ie alternative browsers) can't easily change whatever Google is looking for in the HTTP requests (user-agent header, etc) to identify webview-based browsers vs the few they chose to allow. But it doesn't make sense for regular PCs. Anything an allowed browser can do, "malware" can mimic. Actually, there is one way that it'll work on PCs too - if every google.com website starts using DRM. I almost look forward to that just because of the carnage that will occur in response.

kbenson 6y ago

If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser. > It seems to me that allowing even a single webview-based browser would go against what Google is trying to do. I agree. Other than it being weird to ask/need the system to use a different browser than you are using, and possibly a different browser than what you've set as default if you've set it to one Google doesn't trust for auth, nothing prevents any webview browser from acting like any other webview, and outsourcing to Chrome or Firefox for the authentication to get a good token, as long as you can use a token for full Google account login (which I don't know if you can).

Arnavion 6y ago
>If it's a webview based browser, I think it shouldn't be added. Sorry, that's just the price they pay for using a webview as a shortcut to providing a full browser. Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me. brb writing my own browser called Chremium and petitioning Google to allow it. Apart from that I'll also publish a library that uses the guts of Chremium, called the Chremium Ombodded Framework, which can be embedded in other applications. Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right?
- UncleMeat 6y ago
  > Of course one of the fundamental tenets of software is to not reuse other people's work. Silly me. Many properties of programs are composable. Security isn't one of them. Embedded browsers sniffing credentials is an observed threat to real users.
- kbenson 6y ago
  > Okay. So using a browser library for building a browser is a shortcut, and that disqualifies it from being a "full" browser. Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes. I didn't say it wasn't a full, browser, so please to imply that I did, I said it was a shortcut to providing a full browser (which implies it is a full browser), and it is a shortcut compared to writing one from scratch. Bottom line, if you write software utilizing libraries in a way that is extremely close or identical to a way that other software does and that method is being blacklisted for security, expect problems. It's the same for interpreted code and app stores. For security they don't want programs that can change how they function after review, so they often disallow interpreted code and downloading code to run, and in Apple's case, require their own webview library to view remote sites because of this. They don't even allow a set of other valid webview libraries, they just draw a line in the sand and say "ours only". > Of course any application that uses the COF is indistinguishable from Chremium itself, but Google won't then distrust Chremium because it can't distinguish it from COF any more, right? Probably. Seems like a bad business plan to follow in your snarky alternate reality. A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. You might have had to trade some of the snarkiness in your example for reality, in that case.
  - Wowfunhappy 6y ago
    > Using an off-the-shelf library to provide core browser functionality disqualifies it from being on a list of browsers that do not use and off-the-shelf library to provide that functionality, yes. Epiphany uses Webkit-GTK. In a certain sense of the word, this is indeed an off-the-shelf library, but only in the same sense that Google Chrome uses off-the-shelf Blink. Epiphany a major contributor to Webkit-GTK, and one of its largest users. Should Epiphany ban everyone else from using Webkit-GTK? I don't actually think they can, it's all open source after all. > A better one might be to figure out how Google disambiguates Safari from the iOS webview, Chrome from the chromium webview, etc, and follow the same path. Google is probably doing some kind of ridiculous obfuscated fingerprinting. I don't know that it's viable to work around something like that without cooperation from Google. It would be a constant cat-and-mouse game, with Google having the upper hand.

Wowfunhappy 6y ago

Am I missing something fundamental here? What is the difference between a "webview-based" browser and a browser? If you're on macOS, sure, it's pretty obvious what's a WebView, because Apple explicitly uses the term, and it's their OS. The distinction is one of language rather than technology, but it's a valid distinction nonetheless. On Linux, I don't think the distinction exists. Webkit-GTK is the Linux port of Webkit, and it can be used for anything.

Arnavion 6y ago
There isn't a distinction. That's my point.
- Wowfunhappy 6y ago
  So what did you mean by "it seems to me that allowing even a single webview-based browser would go against what Google is trying to do."
  - Arnavion 6y ago
    kbenson suggested that Google could be petitioned to allow more browsers than the handful they already have. I'm saying that if they allow even a single new webview-based browser, that would implicitly also allow any program using said webview library. This is the opposite of what Google wants. Therefore the only logical conclusion is that Google will not allow any webview-based browsers. In https://news.ycombinator.com/item?id=25156594 https://news.ycombinator.com/item?id=25156594 kbenson clarified that they think Google should not allow any webview-based browsers regardless of whether this hypothetical petition process exists or not. I responded by pointing out how this distinction does not help in any way, because even a new browser written from scratch that gets allowed by Google can then turn around and implement a webview library based on itself anyway. My point is that this entire thing that Google is apparently trying is nonsensical. Maybe it works for phones, where "malware" (ie alternative browsers) can't easily change whatever Google is looking for in the HTTP requests (user-agent header, etc) to identify webview-based browsers vs the few they chose to allow. But it doesn't make sense for regular PCs. Anything an allowed browser can do, "malware" can mimic. Actually, there is one way that it'll work on PCs too - if every google.com website starts using DRM. I almost look forward to that just because of the carnage that will occur in response.