Fixed
Status Update
No update yet.
Comments
ja...@gmail.com
Could you CC the reviewers to this bug so that they can access it - just so we can get the relevant people involved.
Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?
Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?
ed...@gmail.com
adding Chandler, who will have useful opinions on landing mitigations for embargoed vulnerabilities in the LLVM tree
In the past (e.g. when Intel disclosed LVI) our approach was to have patches ready to go and pre-reviewed by appropriate (and appropriately read-in) code owners but not post the patches "for real" until the embargo lifted. Usually this was part of a larger comms strategy where announcements were made in other forums.
Is there an entity beyond security@kernel.org that's coordinating this disclosure?
In the past (e.g. when Intel disclosed LVI) our approach was to have patches ready to go and pre-reviewed by appropriate (and appropriately read-in) code owners but not post the patches "for real" until the embargo lifted. Usually this was part of a larger comms strategy where announcements were made in other forums.
Is there an entity beyond security@kernel.org that's coordinating this disclosure?
[Deleted User] <[Deleted User]>
(re-reading, my second paragraph just repeats what you already laid out. Good independent verification but apologies for not reading the dates more carefully.)
di...@apprekon.com
I don't have permission to CC folks it seems, but it would be worth adding:
* Aaron Ballman <aaron@aaronballman.com> (a code owner for clang who has already reviewed my patch off list)
* Craig Topper <craig.topper@gmail.com> (a code owner for the x86 backend who has already reviewed my patch off list)
x86 is the only confirmed architecture affected. ARM has confirmed they're not affected for their micro-architectures. Not all x86 micro-architectures are affected. Not seeing one particular x86 vendor represented in the LLVM Security Group is...concerning.
> Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?
Yes, but just note that the LLVM code is somewhat a giveaway of what's going on here. GCC has had a similar feature for years; they did not publish the patch under embargo but rather did so publicly back when various spectre and meltdown mitigations were being tested before the development of retpoline. The very first comment on the GCC mailing list was along the lines of "What is this?" I'd like to avoid that here if possible; the name of the game is to not spill the beans to too wide an audience prematurely. Doing so would lose LLVM their (lone) seat at the table for Linux kernel vulnerability disclosures such as this. So we need to be super careful about keeping this need to know.
> Is there an entity beyond security@kernel.org that's coordinating this disclosure?
The encrypted kernel mailing list I'm referring to that is coordinating is not that specific email address. It's more controlled than even that list and members of that list (security@kernel.org) aren't even considered need to know for this one. I don't know whether linux-distros@vs.openwall.org has even been contacted yet; the kernel patch set is up to ~45 patches and growing, and backports will be painful.
* Aaron Ballman <aaron@aaronballman.com> (a code owner for clang who has already reviewed my patch off list)
* Craig Topper <craig.topper@gmail.com> (a code owner for the x86 backend who has already reviewed my patch off list)
x86 is the only confirmed architecture affected. ARM has confirmed they're not affected for their micro-architectures. Not all x86 micro-architectures are affected. Not seeing one particular x86 vendor represented in the LLVM Security Group is...concerning.
> Also is it possible to attach the patch to this bug report so we can see what is involved on the clang side?
Yes, but just note that the LLVM code is somewhat a giveaway of what's going on here. GCC has had a similar feature for years; they did not publish the patch under embargo but rather did so publicly back when various spectre and meltdown mitigations were being tested before the development of retpoline. The very first comment on the GCC mailing list was along the lines of "What is this?" I'd like to avoid that here if possible; the name of the game is to not spill the beans to too wide an audience prematurely. Doing so would lose LLVM their (lone) seat at the table for Linux kernel vulnerability disclosures such as this. So we need to be super careful about keeping this need to know.
> Is there an entity beyond security@kernel.org that's coordinating this disclosure?
The encrypted kernel mailing list I'm referring to that is coordinating is not that specific email address. It's more controlled than even that list and members of that list (security@kernel.org) aren't even considered need to know for this one. I don't know whether linux-distros@vs.openwall.org has even been contacted yet; the kernel patch set is up to ~45 patches and growing, and backports will be painful.
ib...@gmail.com
@oliver: my understanding of the patch is that it is not messing up with the call stack, just using a trampoline. So I assume it would be nice to have the trampoline target in a hot code section as it's likely to be shared by a lot of functions, but that's it, right?
ta...@gmail.com
I have reviewed the backend portion and you can see some comments in https://crbug.com/llvm/33#c9 . Those comments were very minor. I'm happy with the backend portion. I will be around on Jul 12 and can approve quickly as well.
ro...@hicmobile.com
Thanks Craig!
d....@gmail.com
Righto
an...@google.com
ha...@gmail.com
Updated with Craig's latest comments.
> is replacing ret with a jmp absolutely necessary
I think so; it might ultimately not be, but it is how Linux kernel developers have decided to mitigate the vulnerability for the time being. It's not my call though, I was just asked to implement -mfunction-return=/__attribute__((function_return(""))) like GCC has already had now for years. In order for clang to be useful as a drop in replacement for GCC, clang needs to match command line flag, function attribute, and codegen ABI frequently.
> my experience in other domains suggests that messing with the x86 call stack cache does pretty terrible things to performance.
Yep, the performance overhead of this isn't great for sure. An additional set of kernel patches are in the works to try to claw back some performance lost to this approach, but they're not pretty and haven't been vetted quite yet. Time will tell if this is the ultimate solution to this issue, but for now it's what we've got.
> If it is, do we know if this is actually x86 specific?
Not all x86 uArchs are effected. The exploit is specific to uArch's the speculate return addresses in a specific way, and how they behave under specific circumstances wrt. kernel vs userspace privilege boundaries. But there are at least two x86 vendors effected.
ARM commented that their micro architectures were not affected. I'm guessing that they can't vouch for their architectural licensees micro architectures though. That said, I can ask on the encrypted list about architectural licensees, and whether the reporters have tested other architectures or uArchs or contacted other vendors.
> zero-daying every other architecture is also not a super great outcome.
I agree but again it's not my call and there's no stopping the train now; regardless of my toolchain patch the embargo will lift July 12. The researchers that reported the vulnerability may not have access to every uArch under the sun, and I don't know who they have or have not contacted about this vulnerability.
That said, there are non-Linux-kernel vendors participating in the encrypted list IIUC. It might be worthwhile for security representatives at various organizations to get involved.
https://www.kernel.org/doc/html/latest/process/embargoed-hardware-issues.html
There's also other non-Linux operating system vendors on the linux-distros mailing list, which also has early access to embargo'd vuln reports+fixes:
https://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists
FLOSS projects have a catch-22 of needing to develop mitigations behind closed doors, without publishing mitigations before embargo lift (similar to what we're doing here but for the toolchain). Those are the methods open source operating system developers have converged on, and made available to folks developing proprietary operating systems to participate in.
> is replacing ret with a jmp absolutely necessary
I think so; it might ultimately not be, but it is how Linux kernel developers have decided to mitigate the vulnerability for the time being. It's not my call though, I was just asked to implement -mfunction-return=/__attribute__((function_return(""))) like GCC has already had now for years. In order for clang to be useful as a drop in replacement for GCC, clang needs to match command line flag, function attribute, and codegen ABI frequently.
> my experience in other domains suggests that messing with the x86 call stack cache does pretty terrible things to performance.
Yep, the performance overhead of this isn't great for sure. An additional set of kernel patches are in the works to try to claw back some performance lost to this approach, but they're not pretty and haven't been vetted quite yet. Time will tell if this is the ultimate solution to this issue, but for now it's what we've got.
> If it is, do we know if this is actually x86 specific?
Not all x86 uArchs are effected. The exploit is specific to uArch's the speculate return addresses in a specific way, and how they behave under specific circumstances wrt. kernel vs userspace privilege boundaries. But there are at least two x86 vendors effected.
ARM commented that their micro architectures were not affected. I'm guessing that they can't vouch for their architectural licensees micro architectures though. That said, I can ask on the encrypted list about architectural licensees, and whether the reporters have tested other architectures or uArchs or contacted other vendors.
> zero-daying every other architecture is also not a super great outcome.
I agree but again it's not my call and there's no stopping the train now; regardless of my toolchain patch the embargo will lift July 12. The researchers that reported the vulnerability may not have access to every uArch under the sun, and I don't know who they have or have not contacted about this vulnerability.
That said, there are non-Linux-kernel vendors participating in the encrypted list IIUC. It might be worthwhile for security representatives at various organizations to get involved.
There's also other non-Linux operating system vendors on the linux-distros mailing list, which also has early access to embargo'd vuln reports+fixes:
FLOSS projects have a catch-22 of needing to develop mitigations behind closed doors, without publishing mitigations before embargo lift (similar to what we're doing here but for the toolchain). Those are the methods open source operating system developers have converged on, and made available to folks developing proprietary operating systems to participate in.
jo...@entitechsolutions.com
Nick, for us distribution packager to prepare, can you give us an hint whether this patch impacts BPF, which (if I'm not mistaken) always requires LLVM, even for GCC-built Linux?
sa...@gmail.com
From my understanding of the Linux kernel mitigation patches, which I have access to but cannot share outside the encrypted mailing list (much to the dismay of my employer), BPF programs are affected BUT it's the BPF JIT's x86 backend within the Linux kernel which is affected, not the BPF interpreter or the programs themselves. So I don't expect that BPF programs will need to be recompiled; instead distributions may need to either ship kernels with up to date mitigations, or consider disabling the BPF JIT.
That said, it may be better to ask on the linux-distros list once the kernel mitigations are published there (I don't know if they are, please don't spill the beans otherwise!). Once the patches are public, I can point to any formal recommendations they may have.
But right now, it looks like Patch 10/45 addresses the x86 BPF JIT in the corresponding (and unpublished) Linux kernel patches.
My toolchain patch is orthogonal to the x86 BPF JIT. BPF programs aren't expected to be compiled with -mfunction-return, use __attribute__((function_return(""))), or rely on my compiler patch at all. BPF JIT backends may need to call the same runtime hooks that this toolchain patch generates jmps to, as provided by the runtime environment (in this case, the Linux kernel).
Also, it looks like work has started on backporting the kernel patches to the 5.18.y, 5.17.y, and 5.15.y branches of the LTS stable kernel tree.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
(Not pushed publicly, just pointing where that tree is)
Requests have been made for 5.14.y and 4.19.y but it's not clear to me that work has started yet on those branches, or that it will. Distros shipping kernels based on older branches will be encouraged to move to something newer, and something based off LTS (as usual)(some distros DON'T use LTS).
That said, it may be better to ask on the linux-distros list once the kernel mitigations are published there (I don't know if they are, please don't spill the beans otherwise!). Once the patches are public, I can point to any formal recommendations they may have.
But right now, it looks like Patch 10/45 addresses the x86 BPF JIT in the corresponding (and unpublished) Linux kernel patches.
My toolchain patch is orthogonal to the x86 BPF JIT. BPF programs aren't expected to be compiled with -mfunction-return, use __attribute__((function_return(""))), or rely on my compiler patch at all. BPF JIT backends may need to call the same runtime hooks that this toolchain patch generates jmps to, as provided by the runtime environment (in this case, the Linux kernel).
Also, it looks like work has started on backporting the kernel patches to the 5.18.y, 5.17.y, and 5.15.y branches of the LTS stable kernel tree.
(Not pushed publicly, just pointing where that tree is)
Requests have been made for 5.14.y and 4.19.y but it's not clear to me that work has started yet on those branches, or that it will. Distros shipping kernels based on older branches will be encouraged to move to something newer, and something based off LTS (as usual)(some distros DON'T use LTS).
ge...@gmail.com
Thanks Nick for the details!
or...@gmail.com
Thanks for reporting this to us in advance!
I'm representing Rust here, and from what I gather these mitigations are only going to be needed by the Linux kernel. In that case there shouldn't be a need to make a security point release of rustc, as Rust is not yet used in mainline Linux. Is my reading here correct?
I'm representing Rust here, and from what I gather these mitigations are only going to be needed by the Linux kernel. In that case there shouldn't be a need to make a security point release of rustc, as Rust is not yet used in mainline Linux. Is my reading here correct?
ch...@gmail.com
> only going to be needed by the Linux kernel
For the time being, yes. Other operating systems may choose to mitigate the issue similarly, or not at all. I guess there could be another OS, written in Rust, that wants to mitigate the issue using this feature. But I'd perhaps wait for such a feature request from such theoretical developers if such a scenario exists.
> there shouldn't be a need to make a security point release of rustc, as Rust is not yet used in mainline Linux
The rust-for-linux folks might be interested in this eventually, but rustc would need feature development since the LLVM IR function attributes added here are controlled by command line flags and function attributes from clang and the C/C++ code respectively. Rust support isn't in the kernel yet, though I am hopeful it will be, and have been providing review upstream on their patch series.
So without the corresponding front end work to rustc, rolling my llvm+clang change out in a point release wouldn't be useful at this time, IMO.
For the time being, yes. Other operating systems may choose to mitigate the issue similarly, or not at all. I guess there could be another OS, written in Rust, that wants to mitigate the issue using this feature. But I'd perhaps wait for such a feature request from such theoretical developers if such a scenario exists.
> there shouldn't be a need to make a security point release of rustc, as Rust is not yet used in mainline Linux
The rust-for-linux folks might be interested in this eventually, but rustc would need feature development since the LLVM IR function attributes added here are controlled by command line flags and function attributes from clang and the C/C++ code respectively. Rust support isn't in the kernel yet, though I am hopeful it will be, and have been providing review upstream on their patch series.
So without the corresponding front end work to rustc, rolling my llvm+clang change out in a point release wouldn't be useful at this time, IMO.
an...@gmail.com
Sounds good, thanks for the clarification! We'll avoid preparing a Rust point release then, unless after the embargo other OS vendors express interest in such a release.
fo...@google.com
> Sounds good, thanks for the clarification!
Thanks for checking, our Rust team had pretty much the exact same question.
> zero-daying every other architecture is also not a super great outcome.
So I reached out to ARM folks on the encrypted mailing list, as well as the reporters. I heard back from both.
ARM re-iterated that they cannot comment on competing uArch implementations. They recommended the researchers contact Apple directly. ARM mentioned they do "brief" architectural licensees, but don't necessarily share the researchers' whitepaper. They also mentioned the same mailing lists be joined that I mentioned inhttps://crbug.com/llvm/33#c18 .
This is second hand paraphrasing from me though; I don't speak on behalf of ARM in any capacity.
The researchers mentioned they have not tested their exploit on m1/m2 macs, or researched other architectures.
Thanks for checking, our Rust team had pretty much the exact same question.
> zero-daying every other architecture is also not a super great outcome.
So I reached out to ARM folks on the encrypted mailing list, as well as the reporters. I heard back from both.
ARM re-iterated that they cannot comment on competing uArch implementations. They recommended the researchers contact Apple directly. ARM mentioned they do "brief" architectural licensees, but don't necessarily share the researchers' whitepaper. They also mentioned the same mailing lists be joined that I mentioned in
This is second hand paraphrasing from me though; I don't speak on behalf of ARM in any capacity.
The researchers mentioned they have not tested their exploit on m1/m2 macs, or researched other architectures.
or...@onigroup.com.au
I can endeavor to prod people and/or forward anything to SEAR if I'm given something to forward. Researchers are free to email me and have me forward to people if they feel the public facing email is a blackhole.
nm...@gmail.com
If they're super paranoid, they can also use iMessage: oliver@nerget.com
iMessage is secure, I worked on the crypto myself, trust me :D
iMessage is secure, I worked on the crypto myself, trust me :D
an...@zweischneider.de
I've shared your two email addresses with the researcher:
- ohunt@apple.com
- oliver@nerget.com
Otherwise, I believe their email address is:
Johannes Wikner <kwikner@ethz.ch>
- ohunt@apple.com
- oliver@nerget.com
Otherwise, I believe their email address is:
Johannes Wikner <kwikner@ethz.ch>
ta...@gmail.com
So I've talked to Johannes, and it sounds like they're happy to upload details to the google bug tracker, however I have no familiarity with the system so don't know how to grant the required access.
If someone from Google knows, would they be able to?
If someone from Google knows, would they be able to?
n....@gmail.com
[Empty comment from Monorail migration]
ma...@gmail.com
Trying to CC johannes.wikner@gmail.com as that's associated with a google account. Being a person who works with technology, has worked on browsers, etc I failed to notice the CC field.
nm...@gmail.com
Hi there,
I'll hand you our paper and the pocs we made for Intel (Skylake-like), AMD (fam 17h, but likely 15h,16h,18h too) and ARM ThunderX2. As you will find, however, we don't mention ARM at all in the paper. The only ARM machine we have in our lab is a ThunderX2, and it seems to be vulnerable to all kinds of BTI Spectres under this user--kernel threat model. Because these CPUs don't seem have (or use?) the necessary SMC workaround or CSV2 feature, we assumed that they could not be representative for ARM.
As for the AMD and Intel ones, the end-to-end exploits are made specifically for the kernel build we carried out the research on, which was the latest ubuntu/focal kernel available at the time (5.8.0-63-generic).
I'll hand you our paper and the pocs we made for Intel (Skylake-like), AMD (fam 17h, but likely 15h,16h,18h too) and ARM ThunderX2. As you will find, however, we don't mention ARM at all in the paper. The only ARM machine we have in our lab is a ThunderX2, and it seems to be vulnerable to all kinds of BTI Spectres under this user--kernel threat model. Because these CPUs don't seem have (or use?) the necessary SMC workaround or CSV2 feature, we assumed that they could not be representative for ARM.
As for the AMD and Intel ones, the end-to-end exploits are made specifically for the kernel build we carried out the research on, which was the latest ubuntu/focal kernel available at the time (5.8.0-63-generic).
ni...@gmail.com
Sorry Johannes, I missed the above update. I've got this tracked internally as rdar://96815394. It includes your ETH contact + PGP information, so theoretically Product Security should reach out to you reasonably quickly (it is 2am PST however so the people I can prod are still asleep :) ). If you haven't heard anything by I guess around 2am tomorrow in Swiss time.
[Deleted User] <[Deleted User]>
[Deleted User] <[Deleted User]>
Any concern with making this thread public from either the researchers side or the Apple side?
I'd be ok with keeping this thread embargoed until we have a confirmation from Oliver that we would not be zero-daying Apple.
I'd be ok with keeping this thread embargoed until we have a confirmation from Oliver that we would not be zero-daying Apple.
st...@gmail.com
There's no concern on the Apple side, thanks all!
ta...@gmail.com
Patch is reviewed+landed, so it seems like the security bug did its job on coordination. Echo Nick's thanks to everyone who came together to make sure we had a good response.
Given above messages, and more than a week with no objections, I'm derestricting.
Given above messages, and more than a week with no objections, I'm derestricting.
se...@seanhoyt.com
mi...@google.com
Sean: for that, you might want to hit "Me too!" in be https://issuetracker.google.com/35827225 as well.
an...@gmail.com
This critical for us :(
br...@gmail.com
+1
[Deleted User] <[Deleted User]>
Is there any other solution to this?
ta...@gmail.com
now that google have increased the cost for API access.... can we have this very basic feature?
th...@gmail.com
+1
al...@gmail.com
+1
da...@saluteanalytics.com
+1
er...@gmail.com
+1
wa...@gmail.com
+1. This would be extremely helpful.
jt...@gmail.com
+1.
A must have. The info is there, should be simple to expose it.
This is actually a deal breaker for me, since this is crucial part of what I need.
A must have. The info is there, should be simple to expose it.
This is actually a deal breaker for me, since this is crucial part of what I need.
[Deleted User] <[Deleted User]>
Could really use this feature
mi...@gmail.com
+1
he...@gmail.com
Any updates?
be...@gmail.com
+1
From that standpoint the Foursquare API is superior and provides specific categories (+ icons) for each venue type
I would love for the Google Place API to provide similar info. The current Place Types list remains very high level, and an awful lot of venues' primary categories are filed as "point of interest". That's currently the single weakness of the API that is keeping us away from using it vs. Foursquare.
Considering that the Google My Business API already supports a much more specific list of place types than the Place API, it is hard to understand why the same list is not made available in the Place API.
From that standpoint the Foursquare API is superior and provides specific categories (+ icons) for each venue type
I would love for the Google Place API to provide similar info. The current Place Types list remains very high level, and an awful lot of venues' primary categories are filed as "point of interest". That's currently the single weakness of the API that is keeping us away from using it vs. Foursquare.
Considering that the Google My Business API already supports a much more specific list of place types than the Place API, it is hard to understand why the same list is not made available in the Place API.
ra...@gmail.com
Detailed info on the hours of operation and reviews, but no short description of what the place actually is. Incongruent, to say the least.
[Deleted User] <[Deleted User]>
+1
da...@gmail.com
+1
an...@gmail.com
+1
ta...@gmail.com
Can we get an official response to this issue? it has been open for 5.5 years now.
sh...@gmail.com
Please!!!
ti...@gmail.com
Hahaha!
Two years have passed but nothing.
Keep it up, google!
Two years have passed but nothing.
Keep it up, google!
cr...@gmail.com
+1
em...@animalrights.se
+1
as...@gmail.com
+1
hu...@gmail.com
+1
fe...@gmail.com
+1
wa...@umich.edu
Really need this feature in the place API!
yo...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
gc...@gmail.com
+1
dn...@gmail.com
+1
gr...@gmail.com
+1
pr...@gmail.com
+1
om...@gmail.com
+1
ca...@gmail.com
+1
gb...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
an...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
wc...@googlemail.com
As mentioned before, a clear negative vs Foursquare. We are about to decide which API to use for our Product (Google Places vs Foursquare) and this feature alone will probably tip the balance...
ja...@noonan.co
+1
ch...@dailylemons.com
+1
el...@gmail.com
+1
le...@gmail.com
anyone have an update on this? I could really use this in the places API.
iv...@google.com
co...@gmail.com
+1
10...@gmail.com
+1
st...@google.com
[Deleted User] <[Deleted User]>
Was this implemented? The issue was opened in 2013.
ar...@google.com
kb...@gmail.com
+1
cr...@gmail.com
+1 me gustaría que se aplicara esa función
le...@gmail.com
+1 any update?
je...@gmail.com
This was not found in the PLACE API.
Does anyone know how to find in any other API?
Does anyone know how to find in any other API?
an...@gmail.com
+1
ca...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1 does anyone know if this has been added yet?
je...@gmail.com
+1
so...@mailchimp.intuit.com
Looks like this still hasn't been added after all these +1s. I'd really love for this feature to be added to the API. So....plus 1 for me too.
jh...@gmail.com
+10086
za...@net2phone.com
+1
ma...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
ta...@gmail.com
+1
md...@gmail.com
This is really needed in the nearby search response
yv...@gmail.com
+1
jo...@gmail.com
+1 pls google overlords
so...@gmail.com
+1 how come it still hasn't been added...
fa...@gmail.com
+1
vi...@perincherry.com
+1
di...@gmail.com
+1 FIVE YEARS LATER and still not implemented?!
In 5 years we've had 3 different messaging apps, but we can't get this basic functionality?!
In 5 years we've had 3 different messaging apps, but we can't get this basic functionality?!
er...@gmail.com
+1
th...@gmail.com
+1
oh...@melio.com
+1
ma...@gmail.com
Unbelievable that Google does not care about the places API but still raises the prices drastically. I'm out ;)
rw...@gmail.com
How has this not been added to the API yet? This is insane
sm...@gmail.com
+1
sa...@gmail.com
+1
Otherwise we have to try via OSM.
Otherwise we have to try via OSM.
lb...@gmail.com
I'd like to add that it would be nice about restaurants not just to mention which types of restaurant it is (Italian, Chinese, ...), but also if it fits some people's eating-lifestyle.
For example Kosher, Halal, vegan, ...
For example Kosher, Halal, vegan, ...
so...@gmail.com
Any update?
+1
+1
al...@gmail.com
+1
cc...@gmail.com
+1
ja...@gmail.com
+1
ji...@gmail.com
+1
co...@gmail.com
+1. Google team.. It is pretty crazy that this has not been added to the API / documentation yet. Please let us know how this is looking on the roadmap in 2020!
Thanks.
Thanks.
ki...@gmail.com
+1
sk...@gmail.com
+1
ty...@gmail.com
+1
ch...@gmail.com
+1
ma...@googlemail.com
+1
[Deleted User] <[Deleted User]>
+ 1
[Deleted User] <[Deleted User]>
+1
dr...@gmail.com
+1
le...@gmail.com
+1
ag...@gmail.com
Nearly 8 years? +1
1e...@gmail.com
+2
je...@gmail.com
+1
al...@gmail.com
+1
si...@gmail.com
+1
da...@gmail.com
+1
an...@gmail.com
+1
sa...@gmail.com
+1
ro...@itomic.com.au
+1
lo...@gmail.com
+1000
he...@hkmci.com
Hi Support,
Cloud you please help to add a business management consultant place type for our business?
We saw the business management consultant place type is available in Google Maps.
But We search for "synpulse hong kong limited" by Place AutoComplete API.
We only see both types "point_of_interest" and "establishment" from the Api's response.
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=synpulse%20hong%20kong%20limited&key= <PLACE_YOUR_KEY>
Thanks for your help!
Cloud you please help to add a business management consultant place type for our business?
We saw the business management consultant place type is available in Google Maps.
But We search for "synpulse hong kong limited" by Place AutoComplete API.
We only see both types "point_of_interest" and "establishment" from the Api's response.
Thanks for your help!
he...@hkmci.com
Hi Support,
We also want to request to add another cell phone store place type for our business.
We saw the cell phone store place type is also available in Google Maps.
But We search for "Chrisbanks Gsm Center" by Place AutoComplete API.
We saw there are three types "point_of_interest", "store", and "establishment" from the Api's response.
https://maps.googleapis.com/maps/api/place/autocomplete/json?input=Chrisbanks%20Gsm%20Center&key= <PLACE_YOUR_KEY>
Thanks for your help!
We also want to request to add another cell phone store place type for our business.
We saw the cell phone store place type is also available in Google Maps.
But We search for "Chrisbanks Gsm Center" by Place AutoComplete API.
We saw there are three types "point_of_interest", "store", and "establishment" from the Api's response.
Thanks for your help!
at...@gmail.com
+1
ab...@gmail.com
ab...@gmail.com
ab...@gmail.com
yu...@gmail.com
+1
ab...@gmail.com
[Deleted User] <[Deleted User]>
+1
ch...@gmail.com
+1
jo...@gmail.com
Would love this. Thank you!
sa...@gmail.com
Its amazing how Google ignored this request. Seems there is something else going on that Google would not like us to know.
s....@thenormandygroup.com
add this already omg
ad...@gmail.com
7 years of requesting for the same update, yet no change
ro...@itomic.com.au
My guess/assumption is that Google does't wish to share this level of detail (unless maybe we're paying for it) because it might help others compete with Google themselves in the supply of detailed / specialist search directories.
me...@jonhmchan.com
I would absolutely love this feature. +100
al...@gmail.com
just tell us Google, you want money for this info. Take it...
ch...@gmail.com
+++
da...@gmail.com
Comment has been deleted.
ju...@gmail.com
+++
fi...@gmail.com
please
za...@gmail.com
Interesting I'm glad I came here wont waste my time ill find a competitor.
jo...@locktrust.com
Will google ever Acknowledge this (it makes it much more difficult to query each everytime) i figure its a easy field to add in the PlacesAPI (types)
from a food perspective.
category = sushi / steakhouse
from a food perspective.
category = sushi / steakhouse
ad...@wemangia.com
+1
aj...@appscrip.co
+1 :)
ja...@gmail.com
+1 :)
ad...@gmail.com
+1
vi...@gmail.com
+1
[Deleted User] <[Deleted User]>
+1
[Deleted User] <[Deleted User]>
+1
be...@gmail.com
+2
dg...@ardi-tech.com
*1
aa...@dime.io
+1
jo...@locktrust.com
+4
ph...@gmail.com
+∞
jr...@vendasta.com
+1
The google business profile category (seen on google maps) should be returned on the place details response!!! Why doesn't the place details response return the same categories as the locations get api????
https://developers.google.com/my-business/reference/businessinformation/rest/v1/accounts.locations#Location.Categories
The google business profile category (seen on google maps) should be returned on the place details response!!! Why doesn't the place details response return the same categories as the locations get api????
d....@gmail.com
+1
re...@codev.com
+1
ch...@cbsaunders.com
+1
ja...@gmail.com
how is this still pending after 10 years lol
st...@gmail.com
+1
ka...@gmail.com
+1
lu...@gmail.com
+1
hu...@gmail.com
+1
gi...@planckresolution.com
+1
This is a major drawback of using google API. Please fix it ! Better later than never!
This is a major drawback of using google API. Please fix it ! Better later than never!
el...@dilish.app
+1!
be...@gmail.com
+1
na...@mercadolivre.com
Comment has been deleted.
ad...@gmail.com
I predict that people will still be handing this thread +1s in the year 2033.
ts...@gmail.com
Wow, it's been 10 years and the API can't return the type of the place?
pa...@gmail.com
+1
de...@applogist.com
Please make this info avaliable via api
ba...@gmail.com
Veuillez rendre cette information disponible depuis api
us...@gmail.com
+1
mi...@navagis.com
Need to find "Electric Vehicle Charging Stations"
ag...@und3fined.it
+1
[Deleted User] <[Deleted User]>
+1
da...@gmail.com
+1
to...@gmail.com
+11111
ph...@gmail.com
+1
mi...@google.com
We greatly appreciate your patience.
Detailed information about the primary type of each place, as displayed on Google Maps, is now available in
The new API introduces many
primaryTypeDisplayNamefor the Place's primary type as a localized text string.primaryTypeNamefor the Place's primary type, as it is found in thetypesarray.
In addition to this, includedTypes or one or more includedPrimaryTypes),
as well as excludedTypes or one or more excludedPrimaryTypes).
We believe this issue is now fixed, hence marking it as such.
Thanks for working with us!
lb...@gmail.com
@212 Is this available too:
https://issuetracker.google.com/issues/35822953#comment126
?
Can you please show examples of what can be fetched, of a real place?
?
Can you please show examples of what can be fetched, of a real place?
mi...@google.com
Re.
This includes a number of vegan_restaurant, vegetarian_restaurant and many more.
For example API requests and responses, see
lb...@gmail.com
@214 I don't see "Kosher" and "Halal" there. Please add this.
mi...@google.com
Re.
lb...@gmail.com
@216 your link isn't available for me. It's only for Google...
Anyway here:
https://issuetracker.google.com/issues/308633406
Anyway here:
wa...@gmail.com
Comment has been deleted.
wa...@gmail.com
Hi, is there a way to use the "next page token" field in this new api as it was in the previous one?
The "next page token" field was used when the API returned more than 20 results.
Thanks!
The "next page token" field was used when the API returned more than 20 results.
Thanks!
ju...@searchmas.es
+1 PLEASE!
ma...@gmail.com
Please add this feature, it's been requested for more than 11 years now... :)
ke...@gmail.com
+1
ju...@gmail.com
+1 please!
mi...@google.com
Reminder: this issue is closed and no longer monitored.
Re. "next page token" field, please see
For anything else, please
Description
Many Places have detailed information about the type of place that they are. For example, the Place below displays "Indian Restaurant".
It would be great to have this detailed place type information in the Search and Details responses!
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************